Banking as a Service (BaaS) is a model in which a licensed bank, payment institution, or e-money institution exposes its regulated banking infrastructure to third-party businesses through APIs, enabling those businesses to offer financial services to their own customers under their own brand. A financial superapp extends this concept by combining banking and payment services with non-financial services within a single platform. For a SaaS core banking system to support either model, it must provide a specific set of architectural, compliance, and operational capabilities that allow third-party businesses to integrate banking services quickly, configure them to their requirements, and scale them alongside their own growth.
As illustrated in a typical BaaS platform architecture built on a SaaS core banking system, a third-party business connects to the core banking system through its published API layer. The business uses these APIs to configure the banking products it wishes to offer, onboard its end customers, process transactions, and retrieve account data and reports.
The core banking system handles the underlying regulated functions, including customer verification, transaction processing, payment network connectivity, safeguarding, and regulatory reporting, while the third-party business manages the customer relationship and product experience through its own branded interface. The end customer interacts with the third-party business’s application and is unaware of the underlying core banking infrastructure powering the service.
Key Takeaways: #
- A SaaS core banking system intended to power a Banking as a Service (BaaS) platform or financial superapp must provide modular architecture, comprehensive APIs, white-label customisation, integrated compliance capabilities, and a developer-friendly environment as foundational requirements rather than optional features;
- The API layer is the most critical technical requirement for a Banking as a Service platform, as it determines which banking services can be exposed to third-party businesses and developers, how easily those services can be integrated, and whether the platform can support PSD2 open banking obligations alongside commercial BaaS offerings;
- Scalability, regulatory compliance, and security are not features that can be added to a BaaS platform after launch. They must be embedded in the core banking system architecture from the outset, as the volume of transactions, the number of end customers, and the regulatory obligations all scale in direct proportion to the success of the BaaS offering.
What a SaaS Core Banking System Must Provide to Support BaaS and Superapps #
Modular architecture: A modular core banking architecture structures banking capabilities as discrete, independently configurable components, including current accounts, payment accounts, card issuance, money transfers, currency exchange, lending, and compliance workflows. A third-party business building a BaaS product can select and configure the specific modules relevant to its use case, without being required to deploy or pay for the full range of capabilities. Modularity also enables the core banking system to evolve as new capabilities are added, allowing BaaS clients to adopt new services without requiring a platform migration. For a financial superapp, modularity enables the financial service layer to be integrated alongside non-financial services from third-party providers, with each capability operating independently within the broader platform architecture.
API-first design and comprehensive API coverage: The API layer is the interface through which BaaS clients integrate banking services into their own platforms. A BaaS-capable core banking system must provide a comprehensive, well-documented set of RESTful APIs covering the full range of available banking functions, including account opening, balance enquiries, transaction processing, payment initiation, card management, KYC status retrieval, and regulatory report access.
The APIs must be stable, versioned, and supported by complete technical documentation, sandbox environments for pre-production testing, and defined service level agreements covering availability and response times. For payment institutions and e-money institutions subject to PSD2, the API layer must also support the open banking interface obligations discussed elsewhere in this series, with BaaS commercial APIs and open banking regulatory APIs maintained as distinct but complementary interface layers.
White-label customisation: BaaS clients require the ability to present banking services under their own brand identity, with a user interface, colour scheme, and customer communication style consistent with their existing product. The core banking system must support white-label configuration of the customer-facing elements of the banking service, including account interfaces, card designs, notification templates, and onboarding flows, without requiring the BaaS client to build these elements from scratch. This white-label capability allows the BaaS client to deliver a seamless and branded customer experience while relying on the core banking system’s underlying infrastructure and regulatory coverage.
Integrated compliance and regulatory capability: BaaS clients operating under the licence of the core banking system provider rely on that provider to maintain the compliance infrastructure that underpins the regulated services they offer. The core banking system must provide integrated KYC and AML workflows, customer risk scoring, transaction monitoring, safeguarding account management, and regulatory reporting as configurable capabilities available to BaaS clients through the API layer. The system must be capable of adapting these compliance capabilities to the specific regulatory requirements applicable to each BaaS client’s product and customer base, and must maintain audit trails that support both the provider’s regulatory reporting obligations and the BaaS client’s own compliance documentation requirements.
Scalability and performance: A BaaS platform must be capable of handling the combined transaction volumes, user loads, and API call rates generated by multiple BaaS clients simultaneously, without performance degradation for any individual client. The core banking system must be built on cloud infrastructure with elastic scaling capabilities, allowing compute and database capacity to increase automatically in response to demand. Response time service level agreements for API calls must be defined and monitored, as BaaS clients’ end-customer experiences depend directly on the latency of the underlying core banking API. For BaaS platforms supporting real-time payment products, the performance requirements are particularly stringent, as payment network response time obligations must be met end to end across the full API call chain.
Analytics and reporting: BaaS clients require access to data about their customers, transactions, and product performance to manage their business effectively. The core banking system must provide configurable reporting and analytics capabilities that allow BaaS clients to retrieve the data relevant to their specific product set, in formats that can be integrated into their own reporting and business intelligence tools. Regulatory reporting capabilities must also be accessible to BaaS clients where required, enabling them to fulfil their own compliance documentation obligations using data drawn from the core banking system.
Developer environment and tooling: The speed at which BaaS clients can integrate and launch banking services depends directly on the quality of the developer experience provided by the core banking system. This requires comprehensive API documentation that covers all available endpoints, authentication mechanisms, error codes, and integration patterns. Sandbox environments that replicate the production system’s behaviour allow BaaS clients to develop and test integrations without affecting live customer data or production infrastructure. Software development kits (SDKs) for common programming languages reduce the integration effort for BaaS clients building on standard technology stacks. Dedicated developer support channels and a structured onboarding process enable BaaS clients to resolve integration questions efficiently and bring their products to market without unnecessary delays.
Security architecture for multi-tenant BaaS environments: A BaaS platform serves multiple clients simultaneously on shared infrastructure, creating security requirements that extend beyond those of a single-institution core banking deployment. The core banking system must implement strict data isolation between BaaS clients, ensuring that one client’s customer data, transaction records, and configuration cannot be accessed by another client or by unauthorised parties. Access controls must be configurable at the client level, allowing each BaaS client to manage its own user permissions within the boundaries defined by the core banking system provider. Security monitoring must cover the full multi-tenant environment, with anomalous activity in any client’s data or API usage detectable and investigable without exposing other clients’ data.
FAQ: #
What is the difference between a BaaS platform and an open banking API?
- An open banking API is a regulatory requirement under PSD2 that mandates account-holding payment service providers to give authorised TPPs access to customer account data and payment initiation functionality, with the customer’s consent. A BaaS platform is a commercial offering in which a licensed institution makes its full banking infrastructure, including account management, card issuance, payment processing, and compliance capabilities, available to third-party businesses through APIs, enabling those businesses to build and offer financial products to their own customers. Open banking APIs provide access to existing customer accounts; BaaS APIs enable third-party businesses to create and manage new banking products. The two are complementary and may coexist within the same core banking system, but they serve distinct purposes and are governed by different regulatory and commercial frameworks.
What licencing arrangements apply when a third-party business offers banking services through a BaaS platform?
- The licencing arrangement depends on the specific services being offered and the regulatory framework of the jurisdiction. In the most common BaaS model, the core banking system provider holds the payment institution or e-money institution licence, and the third-party business operates as an agent or distributor of the licensed provider’s services. In this arrangement, the provider is responsible for regulatory compliance, safeguarding, AML, and KYC obligations, while the third-party business is responsible for its customer-facing compliance obligations, including marketing, onboarding, and customer support. In some cases, the third-party business may hold its own licence and use the BaaS platform purely as a technology and infrastructure provider. The specific responsibilities of each party must be defined clearly in the contractual arrangements between them and disclosed to the relevant national competent authority where required.
To stimulate innovation and customisation, the core banking software should offer a developer-friendly environment. This involves comprehensive documentation, software development kits (SDKs), sandbox environments for testing and development, and dedicated developer support channels. It allows financial institutions and their clients to extend the functionality of the core banking software, building custom applications on top of it.
By meeting these critical requirements, a SaaS cloud-based core banking system can truly empower financial institutions to offer banking as a service or a superapp. This empowers them to serve as a platform for other businesses to deliver banking services, fostering the creation of innovative financial solutions. Baseella has just that, don’t waste your time and book a demo today to see how we could assist you in developing your own BaaS platform or a superapp.
