The Hidden Cost of Composable Core Banking: API Latency, Vendor Sprawl, and the Risks of Core Banking Integration

The word “composable” has become one of the most fashionable terms in financial services technology. The pitch is simple: choose a lean core banking engine, then assemble best-in-class tools around it, such as sanctions screening, fraud scoring, transaction monitoring, and more. In theory, composable core banking delivers flexibility. In live payment operations, a plethora of core banking integrations can increase API latency, vendor sprawl, and widen the compliance surface area, while Baseella takes a different architectural path.

In practice, for many electronic money institutions, payment institutions, neobanks, and crypto-asset service providers (CASPs) running live operations, extensive core banking integrations often produces three predictable outcomes: slower payments, compounding costs, and a data-protection surface area that expands with every new connection.

In live operations, composable core banking makes every integration a payment dependency.

In this article, we examine the three concrete problems with core banking integrations in payment processing: API latency, total cost of ownership, and GDPR / DORA / PSD2 compliance exposure; and explain the architectural philosophy Baseella was built around from day one.

Part One: The Core Banking Integration Latency Problem Nobody Talks About in the Sales Demo

What actually happens during a payment in a composable stack?

A customer clicks “send” once. In composable core banking, that single action is frequently transformed into a chain of network calls via various core banking integration points that must all resolve before funds can move.

In a typical compliant setup, before a payment order can be dispatched to a correspondent bank, the institution must (at minimum) confirm sufficient funds, screen the transaction and counterparty against active sanctions lists, apply a transaction risk score (proceed / clear / escalate), and post at least three accounting entries: debit the customer account, credit the outgoing settlement position, and record any applicable fee or FX margin.

In composable core banking, sanctions/PEP/adverse media screening, transaction risk scoring, and transaction monitoring are commonly performed by external services. They are not computations inside the core bank system; they are API calls to third-party platforms. This is intentional: composable core banking advocates specialists for each domain, but it relies entirely on flawless core banking integrations.

What does external API latency look like in production?

The problem is not theoretical; it is network physics. Even if an external API is hosted in the same cloud region, an external call has overhead that an in-process function call does not.

Under normal conditions, a well-optimised external API call might return in 80 to 150 milliseconds. Under modest load, or during a brief degradation at the provider’s end, that same call may take 300 to 500 milliseconds. During an incident, it may time out entirely, which is not unusual.

In composable core banking, three external calls per payment, i.e., a sanctions check, a risk score, and transaction monitoring rules check – means that under normal conditions you add 160 to 300 milliseconds of pure network latency to every transaction before you have even posted an accounting entry. At production scale, real-world p95 latency for a fully composable payment flow routinely reaches 400 to 600 milliseconds on the compliance path alone. That is before your own orchestration logic and before the outbound call to your correspondent bank.

For most rails, this has been tolerable. But the landscape is changing. SEPA Instant and the UK’s Faster Payments scheme impose end-to-end processing expectations that leave less margin for latency accumulated through multiple external hops. The European Banking Authority (EBA) has progressively tightened expectations around real-time payment reliability, including the handling of scheme-mandated processing windows. As real-time payment infrastructure becomes the baseline expectation, institutions relying heavily on complex core banking integration will be pushed to explain where processing time goes.

How does Baseella handle the compliance path without external calls?

Baseella makes a deliberate engineering choice: every step of the compliance and accounting path runs inside the platform boundary, without an external API call, until the payment order is ready to be dispatched to the correspondent bank. That is the only external call in the fiat payment processing flow.

Baseella is built on a SOA (Service-oriented architecture) architecture in which each compliance and operational function – sanctions/PEP/adverse media screening, transaction risk scoring, transaction monitoring rules, accounting and ledger entries – runs as an independent service with its own database, while communicating to the RESTful API Gateway inside the platform boundary rather than over the public internet. 

In practice, GraphQL Federation allows the Baseella Super Graph to fan out queries to the Accounts module (balance check), the Block lists module (sanctions), the Scoring module (risk score), and Transaction monitoring (rules check) simultaneously, receive all responses, and then proceed to the Transactions module to post accounting entries. The compliance resolution happens in parallel, within the platform, in millisecond intra-service time.

The result is a payment path where the only external network latency is the correspondent bank call. Everything else resolves internally.

Why does this matter for operational resilience beyond latency?

Latency is the visible symptom; availability dependency is the deeper issue. In composable core banking, every external API tied to your core banking integration is a potential single point of failure. 

If a sanctions screening provider has an incident, you face an immediate operational dilemma: block all outgoing payments until recovery, or let payments proceed without screening. Neither answer is acceptable. When screening runs inside your platform, that dilemma changes.

What does transaction monitoring actually require, and why does it belong inside the platform?

Transaction monitoring is often sold as a separable component in composable core banking: send transactions to a monitoring vendor, receive alerts back. That framing ignores the reality that monitoring decisions are only as good as the context they can access.

The rules that matter – velocity checks, structuring detection, round-trip identification, geographic risk escalation, counterparty clustering – require full transaction history, onboarding risk profile, current risk score, account type, initiation channel, and the behavioural baseline established over time. If monitoring is separated from the system that holds this context, you either replicate that data externally (increasing GDPR and security exposure) or you monitor against a weaker dataset that produces weaker decisions.

Baseella’s transaction monitoring runs natively inside the platform with direct access to the customer profile, the full transaction history in the Transactions database, risk scores maintained by the Scoring module, and onboarding and KYC data held in the Clients database. Rules are configured by the client’s compliance team and can be updated without vendor involvement and without a deployment cycle. Alerts flow into the same compliance operations workflow used for case management, without a screen switch, a separate login, or a ticket raised to a third-party case management vendor.

For CASPs, one qualification is unavoidable. On-chain AML/CTF screening and Travel Rule compliance require external integrations because blockchain analytics vendors operate proprietary datasets that core platforms cannot replicate. Baseella integrates externally to obtain those signals, then routes results into the same internal monitoring workflow so the MLRO can act inside one operational queue.

Part Two: The Total Cost of Ownership in Core Banking Integration

What does a complete composable stack actually cost?

Composable core banking is, by definition, incomplete. The core handles the ledger and basic transaction logic. Entire or significant compliance infrastructure that a regulated payment or e-money institution needs to operate must be obtained elsewhere: sanctions screening, PEP monitoring, adverse media checks, transaction monitoring, customer risk scoring, request for information (RFI) processing.

In composable core banking, “elsewhere” typically means multiple specialist vendors, each with its own licensing model, integration work, and operational overhead. A realistic stack for a newly licensed EMI or PI usually includes the core platform licence plus dedicated tools for sanctions/PEP, fraud or scoring, AML/CTF monitoring with case management, and often a reporting layer if it is not native.

And integration is not a one-time checkbox. APIs change, vendors release new versions, and compliance requirements evolve. Each core banking integration becomes an ongoing engineering obligation.

What are the realistic annual costs?

A conservatively assembled composable stack for a small to mid-size PayTech processing perhaps 50,000 to 200,000 payments per month typically carries combined licensing costs of €80,000 to €250,000 per year across the compliance and monitoring components alone, excluding the core licence. One-time integration costs can range from €30,000 to €80,000. Ongoing core banking integration maintenance i.e., API changes, cross-system debugging, and reporting connectors typically add €12,000 to €24,000 per year in headcount or external development costs.

The cost compounds again in governance. This is where composable core banking becomes expensive in ways that are easy to miss, especially in the beginning. Each vendor relationship requires a Data Processing Agreement and security due diligence. If you have five external providers in the payment chain, you have five entries in your DORA register, five sets of contractual ICT obligations, and five vendors to manage during a regulatory review.

Baseella publishes its cost savings estimates transparently: clients typically save at least €80,000 annually on third-party AML/CTF and financial crime tools alone, plus a further €70,000 in reporting specialist and accountant resources that become redundant when financial and regulatory reporting (including AML/CTF/fincrime report) is generated natively within the platform.

What about the hidden costs that appear only in year two or three?

The most insidious costs in a composable stack surface as you scale. Sanctions providers often price per check or per volume; as payments grow, the screening bill grows. – sometimes in ways not captured in year-one plans. Transaction monitoring vendors similarly price on tiers that become painful precisely when transaction margins are under pressure.

Then there is incident time. In composable core banking, a failed payment or an incorrect risk score can originate in any one of several systems. Resolving it requires correlating logs across vendor portals – a direct consequence of fragmented core banking integrations. Work that should take an hour can take a day when the trail is fragmented. When compliance functions run within one platform with a unified audit trail, incident investigation is proportionally simpler.

Part Three: Securing the Core Banking Integration Perimeter

What data leaves your system with every composable API call?

This is rarely asked directly in composable core banking sales conversations, but it is fundamental. Every external API call on the payment path carries data. A sanctions call can include customer identity attributes, and a scoring call can include full transaction details. 

A scoring call can include full transaction details (amount, currency, origin, destination, timestamp, channel) and sometimes historical patterns used to contextualise a score.

In composable core banking, each call is a transfer of personal data to a third-party data processor under the GDPR. Each requires a legal basis, a Data Processing Agreement meeting Article 28, security due diligence, and if data leaves the EEA, ensures appropriate transfer mechanisms under Chapter V. For a PayTech running composable core banking and processing thousands of transactions per day, that is a continuous, high-volume data flow to external parties.

What are the specific GDPR obligations this creates?

Under GDPR Article 5(1)(c), data minimisation requires that personal data be adequate, relevant, and limited to what is necessary for the purpose. Under Article 32, the controller retains responsibility for end-to-end security when data transits over the public internet to an external provider. Under Article 33, a personal data breach at a processor exposing transaction data you transmitted must be reported to the supervisory authority within 72 hours. The obligations follow the data, and the data follows every core banking integration API call.

What does DORA add to this picture for the EU entities, and what does the FCA’s PS21/3 require of UK firms?

The EU Digital Operational Resilience Act, fully in force since January 2025, creates a structured regime for ICT third-party risk management. DORA requires in-scope entities (including EU-licenced payment and e-money institutions) to maintain a register of ICT third-party providers supporting critical or important functions, perform risk assessments, establish contractual arrangements covering audit rights, data security, service continuity, and exit, and test resilience including third-party failure scenarios.

UK firms have equivalent expectations under the FCA’s PS21/3 on Operational Resilience, which took full effect in March 2025. PS21/3 requires firms to identify important business services, set impact tolerances, and map and test dependencies across the supply chain so they can remain within tolerances during severe-but-plausible disruption.

The practical implication for composable core banking is that every additional core banking integration dependency on the payment execution path is another thread in your mapping, another scenario in your testing programme, and another vendor in your governance workload. A stack with five external compliance providers means five ICT relationships to document, test, and maintain. For a small team, this is not marginal overhead.

Baseella reduces the external ICT dependency surface in fiat payment processing to the correspondent banking relationship. Sanctions screening, PEP checks, adverse media, and AML/CTF monitoring run inside the Baseella platform boundary. From a DORA and PS21/3 perspective, these are internal platform capabilities, not third-party ICT services.

What about the sanctions and adverse media data that must come from external sources?

This is the key distinction. Sanctions list data must be sourced externally: the raw content of OFAC, HMT/OFSI, EU, and UN consolidated lists. The same applies to PEP databases and adverse media feeds. The architectural question for composable core banking is not whether you use external data; it is when and how.

Baseella handles sanctions and adverse media data through an asynchronous synchronisation worker (the Block lists worker) that pulls list updates and stores them inside the platform’s AML/CTF & KYC database. Payment-time screening then queries a locally held, continuously updated dataset. The external provider is called per update cycle, not per transaction.

The GDPR implications are significant. External data transfer becomes a list synchronisation event, not a customer data transfer. No customer names, transaction details, or account identifiers need to leave the platform during screening. The decision is made inside the regulated perimeter, on data you control.

Baseella’s Architectural Philosophy: A Smarter Approach to Core Banking Integration

The architecture described here is deliberate, not accidental. Baseella was built by co-founders with direct operational experience of what regulated payment and e-money institutions, neobanks, and CASPs need to run compliantly and efficiently without the fragility of a heavily integrated third-party ecosystem.

Baseella is built on open-source technology, with each SOA (Service-oriented architecture)  running its own PostgreSQL database for true data isolation between compliance, accounting, and operational functions. Elasticsearch supports search and analytics across transaction data. Internally, GraphQL Federation provides the service-to-service API layer between API gateways and core services, enabling the Supergraph to fan out requests across multiple subgraphs simultaneously. This allows balance checks, block list screening, risk scoring, transaction monitoring, to run in parallel and in-process rather than sequentially over external network calls. This is why Baseella avoids composable core banking patterns that push compliance decisions out to fragile core banking integration APIs.

The consequence for payment processing is simple. When a payment is initiated, Baseella resolves balance checks, compliance screening, risk scoring, transaction monitoring rules, and accounting entries internally. The first and only external API call in the fiat payment flow is the outbound payment instruction to the correspondent bank. For crypto-asset transactions, there is an additional call to the on-chain and Travel Rule provider. The boundary – internal for compliance, external only for settlement and unavoidable crypto signals – is an auditable design choice, not a marketing claim.

For PayTechs evaluating composable core banking or an integrated alternative, the revealing questions are operational: how many external systems are called per payment through your core banking integrations, whose infrastructure customer data transits, how many DORA and PS21/3 registers you must maintain, and what p95 payment latency looks like at realistic load. Those answers usually tell you more about true cost and risk than any feature table.

Baseella is a core banking and payments platform built for electronic money institutions, payment institutions, neobanks, money service businesses, and crypto-asset service providers. To see how Baseella handles payment processing, compliance, and reporting in a single integrated platform, visit Baseella online or schedule a demo.