Three companies are usually involved in a product that looks like a single bank. There is the brand you see, which owns the app and the customer relationship. There is a technology provider that supplies accounts, cards, payment rails and a compliance layer through an API. And there is a licensed institution, either a bank or an electronic money institution, on whose permissions the whole thing legally sits.
Banking-as-a-Service is the commercial packaging of that middle and bottom layer. A company that could never obtain a banking licence, or that has no interest in the capital and reporting that comes with one, rents access to the regulated functions and puts its own brand on top.
What the licence holder actually provides
Four things, and the distinction between them matters when you are reading a contract. Account issuance, meaning real IBANs or account numbers that can receive funds. Payment execution across the rails the institution is connected to, typically SEPA and SWIFT in Europe, plus local schemes. Card issuance through a scheme membership with Visa or Mastercard, usually as a principal member sponsoring the programme. And the regulatory perimeter itself: the AML programme, the transaction monitoring, the reporting to the supervisor, and responsibility for who is allowed on the platform.
The technology provider adds the parts a bank is usually bad at. Modern APIs, webhooks that fire in seconds rather than by overnight file, a ledger you can query, onboarding flows, and a dashboard that a non-banker can operate. Some BaaS firms hold their own EMI licence and do both jobs, which shortens the chain by one party and is generally the arrangement worth paying more for.
Bank money versus e-money, which is the real fork in the road
Two structures dominate, and they are not equivalent for the end customer.
| Sponsor bank model | EMI model | |
|---|---|---|
| Underlying permission | Full banking licence | Electronic money institution |
| Client funds | Deposits on the bank's balance sheet | Safeguarded in segregated accounts, not lent out |
| Deposit insurance | Covered by the national scheme within limits | Not covered; protection is the safeguarding regime |
| Interest on balances | Possible | Prohibited on e-money in the EU |
| Typical speed to launch | Slower, heavier diligence | Faster, lighter capital |
Neither is better in the abstract. What is unacceptable is a brand that markets e-money balances in language that implies deposit protection. The safeguarding regime for EMIs is genuinely protective, since client funds are held apart from the institution's own money and cannot be used for lending, but the recovery process after an insolvency is an administration, not a compensation payout in days. Our comparison of neobanks and banks goes through what that means for a business holding an operating float.
Where trading firms meet BaaS
A broker or prop firm rarely sets out to build a neobank. It meets the stack sideways, through three needs.
The first is client deposit collection. Instead of one corporate IBAN that every client wires into, with a reconciliation clerk matching references by hand, the firm issues a dedicated virtual IBAN per client from a BaaS provider. Money arriving on that IBAN can only belong to one account, so allocation becomes automatic and the reconciliation problem largely disappears. The catch is IBAN discrimination: a Lithuanian or Belgian IBAN issued to a Spanish client is legally required to be accepted for SEPA payments and is nevertheless rejected by some payroll systems and some banks.
The second is payouts. Prop firm trader rewards and broker withdrawals both need mass payment execution with proper status callbacks rather than a CSV upload and a hopeful wait, which is the same requirement covered in our piece on payout rails.
The third is corporate banking itself. Trading firms are classified high risk by most banks, and a BaaS provider whose sponsor is comfortable with the sector may be the only realistic route to an operating account. That is also the fragility: the sponsor's appetite, not the provider's sales team, decides whether your account survives the next portfolio review.
The risks that get discovered late
Concentration is the first. Several BaaS platforms have been forced to move client programmes at short notice when their sponsor exited the segment or a supervisor required remediation. If your entire deposit flow runs through one provider, that event is an outage for your customers and a support crisis for you. The same reasoning behind a multi-PSP strategy applies here: a second rail, tested and live, even if it carries a fraction of the volume.
Read the offboarding clause before the onboarding one. Notice period, whether client funds can be returned to source or must be paid to the firm, and who owns the account numbers. If the IBANs die with the contract, every client you asked to save that IBAN has to be re-onboarded.
Compliance ownership is the second. The licence holder carries the regulatory obligation, so it will impose its own AML programme on your customer base whatever your own procedures say. Expect prescribed onboarding data, sanctions screening you cannot override, and holds you cannot release. Firms that treat those as a technology problem rather than a shared obligation lose the relationship.
The third is unit economics. BaaS pricing usually combines a platform fee, a per-account fee, and per-transaction pricing on each rail. At low volume the platform fee dominates and the model looks expensive. The break-even point sits further out than most business plans assume, and it is worth modelling before signing a two-year term.
How to run the diligence
Establish the chain first: which entity holds the licence, in which country, under which supervisor, and can you see it on the public register. Ask where client funds sit and whether the safeguarding accounts are named. Ask what the sponsor's stated appetite is for your sector in writing, not in a call. Then test the API against your actual reconciliation flow, because a webhook that arrives reliably in two seconds and one that arrives eventually are different products, and only one of them lets you credit a client account automatically.
At SINGUARD we build the software layer that sits above all of this. The Broker CRM reconciles deposits, tracks balances and drives payouts, and it is deliberately provider-agnostic: the banking relationship is the operating firm's to hold, and the firm remains responsible for its own licensing and compliance.
"Ask one question of any BaaS provider before you sign: whose balance sheet holds the client money, and what happens to my customers the week that institution decides it no longer likes my sector."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- BaaS splits a bank product into three parties: the consumer brand, a technology provider with the API, and the licensed institution carrying the permissions.
- A sponsor bank holds deposits covered by a national scheme; an EMI safeguards funds instead, which protects them but is not deposit insurance.
- Trading firms mainly use BaaS for per-client virtual IBANs, mass payouts, and an operating account in a sector banks class as high risk.
- Sponsor appetite can change with no fault on your side, so a tested second rail and a readable offboarding clause matter more than pricing.
Frequently Asked Questions
Who holds my money in a Banking-as-a-Service setup?
The licensed institution at the bottom of the stack, not the app brand and usually not the technology provider. Under a sponsor bank it is a deposit on the bank's balance sheet. Under an electronic money institution it sits in safeguarded accounts held apart from the institution's own funds.
Is an EMI account as safe as a bank account?
It is protected differently. E-money must be safeguarded and cannot be lent out, which is a real protection, but there is no deposit compensation scheme paying out quickly after a failure. Recovery runs through an administration process instead.
Can a broker or prop firm use BaaS for client deposits?
Many do, typically issuing a virtual IBAN per client so incoming transfers reconcile automatically. Acceptance depends on the sponsor's appetite for the sector, and the operating firm still carries its own licensing and AML obligations regardless of what the provider supplies.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.