Banking-as-a-Service (BaaS) is a model in which a licensed financial institution or regulated provider makes capabilities such as accounts, IBANs, payments, cards and foreign exchange available to another business through APIs and an operating agreement. The fintech builds its product around that infrastructure, while responsibilities for onboarding, compliance, safeguarding, transaction processing and customer support are divided according to the regulatory and contractual model.
From the partnership side, the API is only the visible part. The relationship underneath it determines who approves customers, who controls the movement of funds, who handles exceptions and who answers when something goes wrong. BaaS can accelerate access to regulated infrastructure, but it does not remove the need to define those responsibilities clearly.
As of July 2026, with a primary focus on EMIs, payment institutions, neobanks and embedded-finance products operating in Europe.
Tuesday Tech #5 - what Banking-as-a-Service is and how fintechs use it.
Banking-as-a-Service is the delivery of regulated financial capabilities through technology and commercial partnerships. Depending on the provider and the operating model, those capabilities may include account and IBAN issuance, access to payment rails, card issuing, foreign exchange, safeguarding arrangements, customer verification and transaction-monitoring services.
BaaS is not a separate type of financial-services license. It is a delivery model. The regulated services still sit under the permissions of a bank, electronic money institution, payment institution or another appropriately authorized provider, and a single proposition may rely on more than one regulated entity. In Europe, PSD2 governs the provision of payment services, while the E-Money Directive provides the framework for issuing electronic money. The precise permissions and responsibilities depend on what is being offered, where it is offered and how the parties are structured.
This is also why BaaS should not be confused with a banking app or core banking software. The app is the customer-facing experience. The core banking platform manages accounts, balances, ledger entries, payments and operational records. BaaS provides access to regulated capabilities and external rails. A fintech product may need all three, but they are not interchangeable.
The distinction I keep drawing for founders is that the API does not create the operating model by itself. It connects the systems. The contractual relationship, compliance framework and division of responsibilities determine how the service can actually be used.
Fintechs use BaaS when their product needs regulated financial infrastructure that they do not want, cannot yet, or do not need to build and access directly. A neobank may use a partner for account issuance and payment connectivity. A payroll platform may need local or cross-border payouts. A marketplace may embed wallets, collections and merchant disbursements. A crypto business may need fiat accounts and payment rails alongside its digital-asset infrastructure.
The customer sees one product, but several systems and institutions may sit behind it. A typical flow starts with the fintech's interface and onboarding journey, passes customer and transaction data into the core banking and compliance layers, and then reaches the provider responsible for the relevant account, payment, card or foreign-exchange service. The provider may approve the customer or transaction according to its own risk appetite, while the fintech performs the tasks assigned to it under the operating model.
What I see across partner discussions is that the arrangement often develops in stages. At launch, a company may rely heavily on external providers because this reduces the number of direct scheme relationships and integrations it must establish before serving customers. As volumes, regulatory permissions and operational capacity grow, it may add a second provider, negotiate direct access to selected rails or bring certain functions under its own authorization. The strongest architectures make that progression possible without forcing the business to rebuild its product around every change of partner.
Advapay's Banking-as-a-Service hub is designed around this connected model: partner services and payment infrastructure are integrated with the Macrobank core so that accounts, transactions, balances, reconciliation and reporting can be managed within one operational environment.
A BaaS provider may supply regulated account or payment services, access to payment and card schemes, account identifiers, safeguarding arrangements, compliance controls and the APIs required to connect them. It also retains the regulatory obligations attached to its own permissions and to the services it provides.
The fintech's responsibilities depend on the structure. An independently authorized EMI or payment institution using a BaaS provider for rail access will have a different role from an agent, distributor, programme manager or technology company operating within a sponsor's framework. The end customer may contract with the fintech, the regulated provider or both. Customer due diligence may be performed through the fintech's interface but approved under the provider's policy. Transaction monitoring, complaints, fraud operations, reporting and safeguarding reconciliation may likewise be divided between the parties.
This is why "the provider handles compliance" is not a sufficient operating model. Before implementation begins, the parties need to agree who owns each control, who makes decisions, what information must be exchanged, how quickly exceptions are handled and how evidence will be produced for audits or supervisory requests. The same clarity is needed for incidents, customer complaints, frozen transactions, rejected payments, data requests and the termination or migration of the relationship.
The fintech does not automatically inherit every regulatory duty, and it does not automatically transfer every duty to the provider. Each party remains accountable for the obligations that apply to it under law, regulation and contract. The practical objective is to make that boundary explicit and support it with systems, procedures and service levels.
This is where the core banking and compliance layers matter. Onboarding workflows, AML and KYC controls, transaction records, reconciliation and audit trails need to reflect the agreed responsibility model. When those capabilities are connected to the BaaS relationship rather than managed through manual workarounds, the partnership is easier to operate and oversee.
Founders often focus on the API, but the harder work is agreeing what happens around it: who approves the customer, who monitors activity, who safeguards funds, who handles an incident and who answers to the regulator. A strong BaaS partnership makes those responsibilities explicit before integration starts.
BaaS is usually attractive when a fintech needs to reach the market without establishing every regulated relationship and payment connection directly. It can reduce the number of integrations required at launch, provide access to capabilities that would otherwise take longer to arrange and convert part of the infrastructure burden into contracted services.
Direct access offers a different set of advantages. A licensed institution with sufficient scale may seek direct scheme participation or bilateral banking relationships to gain more control over service levels, economics, product design and provider concentration. That route also brings additional technical, compliance, treasury, operational and governance responsibilities. Eligibility is not determined by transaction volume alone; it also depends on the institution's permissions, operating history, risk profile, geographic scope and the relevant scheme or partner requirements.
For many fintechs, the answer is not a permanent choice between BaaS and direct access. A company may use BaaS for one market, hold a direct relationship for another and retain specialist providers for cards, foreign exchange or local payment methods. The more useful question is which capabilities should be partnered today, which may justify direct access later and whether the underlying architecture can support that transition.
Provider selection therefore needs to cover more than API documentation and price. Risk appetite, accepted customer segments, geographic and currency coverage, safeguarding, reconciliation, service levels, data access, continuity arrangements and exit provisions all affect whether the relationship will work in practice. Advapay's BaaS provider checklist explores that evaluation in more detail.
The wider launch decision - how banking access fits alongside licensing, technology and operational readiness - is covered in How licensing, technology and banking access fit together in a fintech launch. For the underlying payment routes, see Advapay's comparison of SEPA and SWIFT.
Advapay supports BaaS-based fintech launches by combining the Macrobank core banking platform, implementation services, licensing-project consulting and a marketplace of partner integrations. The objective is to connect the business model, operating responsibilities and external providers within one implementation plan rather than treat the core, the license and banking access as unrelated projects.
Macrobank provides the operational layer for customer records, accounts, balances, ledger entries, payments, fees, reconciliation and reporting. Partner integrations can connect that layer to account, payment, card, foreign-exchange, identity and compliance services according to the client's required model. Because the core remains separate from any single external provider, a fintech can design for additional or replacement relationships as its coverage and scale change.
Advapay is a B2B technology and consulting company; it does not itself provide bank accounts, payment services or other regulated financial products to end customers. Where a project uses regulated BaaS or banking services, those services are supplied under the permissions and contractual framework of the relevant licensed partner. Advapay's role is to provide the technology, implementation and consulting work needed to connect those services to the fintech's operating model.
Across more than 100 licensing and platform projects, the recurring lesson has been that partner onboarding should run alongside technology and regulatory preparation. Waiting until the platform is largely complete before testing the business against provider risk appetite can leave a team with a technically finished product that still cannot access the accounts or rails it needs.
Banking-as-a-Service is not a shortcut around regulation, and it is not simply a collection of endpoints. It is a way to use regulated capabilities and established financial infrastructure through a defined relationship, while keeping the product, technology and operational responsibilities aligned.
The API determines how systems communicate. The partnership determines which customers can be served, how money can move, what controls must operate and how problems are resolved. Fintechs that understand both sides are better placed to select suitable providers, avoid manual gaps and adapt their infrastructure as they grow.
If you are assessing whether BaaS fits your business model, speak to the Advapay team about the core banking, partner-integration and licensing-project requirements behind the launch.
Hamid Najafi, Director of Business Development, Advapay
Banking-as-a-Service is a model in which a licensed financial institution or regulated provider makes capabilities such as accounts, payments, cards and foreign exchange available to another business through APIs and an operating agreement. The fintech uses those capabilities to build its own customer proposition.
No. BaaS is a commercial and technology delivery model, not a separate regulatory authorization. The underlying services must still be provided under the permissions of the relevant bank, electronic money institution, payment institution or other authorized provider.
No. A banking app is the customer-facing interface, while core banking software manages accounts, balances, ledger entries and operational records. BaaS connects the product to regulated services and external financial infrastructure. A fintech may use all three together.
It depends on the services, jurisdiction and operating model. Some businesses operate within a licensed provider's agent, distributor or programme structure, while others hold their own authorization and use BaaS for accounts, rails or specialist services. The arrangement must be assessed against the activities the fintech will perform.
Responsibility is divided according to applicable law, the regulatory structure and the contracts between the parties. The provider remains responsible for obligations attached to its permissions, while the fintech remains responsible for the controls and activities allocated to it. The division should be documented at process and control level before launch.
Depending on the provider, BaaS may include accounts and IBANs, domestic and cross-border payments, card issuing, foreign exchange, safeguarding arrangements, customer verification, transaction monitoring and reporting interfaces. Coverage and responsibility vary between providers.
No. Early-stage fintechs use BaaS to reduce the infrastructure and partnership work required at launch, while licensed and established institutions use it to enter new markets, add products, diversify providers or supplement direct relationships.
