What business result does the bank get
A bank that exposes core banking as a set of managed APIs stops being a bottleneck for its own channels and partners. Concrete figures from HSBC's public case: application development time fell by 75%, new features ship every two weeks instead of quarterly, thousands of APIs were built, and the developer portal covers 30+ markets and three global business lines (Salesforce/MuleSoft, 2019; Intelligent CIO, 2019).
These are two different business effects from one investment. First is open banking: the core (credit cards, mortgages, payments) is opened to partners and fintechs as a product, creating new revenue channels. Second is the speed of your own digital products: a feature is assembled from ready-made APIs, not from a new mainframe integration.
Problem: the core is not built for channels and partners
Core banking systems (mainframe, core banking system, card processing, lending) were designed as systems of record, not as product APIs for the outside world. Every new channel - mobile banking, mortgage rate marketplace, fintech aggregator - requires a separate point integration. This creates point-to-point spaghetti: expensive to maintain, slow to launch, and risky from a security and regulatory standpoint (PSD2, GDPR, PCI DSS).
Regulators are increasing pressure: PSD2 and open banking directly require banks to provide customer data to third-party providers through APIs with consent management (MuleSoft, PSD2 whitepaper). Without a managed API layer, this becomes a one-off compliance project rather than a product capability.
Solution: a three-layer API-led architecture on Anypoint
MuleSoft implements the API-led connectivity approach - the core is not rewritten or forked, and business logic plus decoupling live in the API layer alongside systems of record (Accutive FinTech):
- System API connect directly to the core banking system, processing, and lending systems, and abstract the legacy. The channel no longer knows the mainframe details.
- Process API orchestrate business logic and transform data into standard open banking formats (transformation in Anypoint / DataWeave).
- Experience API provide each consumer with its own contract: one for the mobile app, another for the partner site, and a third for the fintech. They are published through Anypoint Exchange and the developer portal.
The key principle of separation: a System API written once on top of card processing is reused by dozens of product teams. This is where HSBC gets its "thousands of APIs" and the -75% effect - a new team does not integrate with the core again, but uses a ready-made managed contract.
Security and compliance as policies, not code
Security is moved into API Manager and API Gateway as declarative policies instead of being coded into each service: OAuth authentication, rate limiting, threat protection, versioning, fine-grained access control (Accutive FinTech). For open banking, this provides consent management and platform-level auditing. In a public case with partner Accelirate, this approach delivered 99% compliance with PSD2, GDPR, and PCI DSS and reduced legacy integration costs by 40% (Accelirate).
Impact on digital products
When the core is available as an API catalog, the product is assembled rather than integrated. HSBC shows customers a single view of spending across all accounts - a composition of data from different legacy systems through an API layer, not new core development (Intelligent CIO). Open banking creates new revenue channels: HSBC's Mortgage API is embedded into home-search sites so buyers can immediately see properties they are preapproved for (Intelligent CIO). A similar pattern is seen at Coast Capital, where MuleSoft connected core banking, lending, and the digital platform to deliver an end-to-end customer experience (MuleSoft, Coast Capital).
Process flow (text)
Core banking systems (core banking system, card processing, lending, mainframe) -> layer System API (one contract per system, legacy abstraction) -> layer Process API (orchestration, alignment with open banking standards) -> API Manager / Gateway (OAuth, consent, rate limiting, audit) -> layer Experience API in Anypoint Exchange -> three consumer types: internal product teams (mobile/web banking), partner channels (home-search sites, marketplaces), external fintechs (PSD2 TPPs). Feedback loop: API usage metrics from monitoring feed back into product decisions about catalog growth.
Business process takeaway
Redesign the product launch process: instead of "new channel = new core integration," make "find or publish a reusable API" a required step. Assign System API owners on the core-banking side and measure the share of products assembled from existing APIs. It is the reuse rate, not the number of integrations, that converts into HSBC-level results: -75% development time and releases every two weeks instead of quarterly.
