Microservices architecture in banking

Microservices architecture in banking means decomposing a bank's core systems into small, independently deployable services, each owning one business capability: payments, KYC, loan origination. Instead of one monolith where changing the interest-rate engine means redeploying the platform, teams release and fail independently. In a regulated European bank that is harder than it sounds, because a service boundary is also an audit boundary, and since DORA started applying in January 2025 the dependency map behind those boundaries is something a supervisor can ask to see. This article covers how the architecture works under those constraints, what it costs, which platforms shape the space, and where the implementation risk actually sits.

What microservices architecture actually means for a bank's technology stack

The word is used loosely in banking, so start with the definition. A monolithic core banking system, the kind still running most tier-one institutions, packages every function into a single deployable unit, so updating one module means testing and releasing the whole thing. Microservices invert that. The consequences reach into engineering staffing, vendor contracts, and the evidence a bank produces when a regulator asks which version of what processed a given payment.

A microservice is a bounded, independently deployable process that communicates over a defined API, usually REST or event-driven messaging. The contrast with a monolith is easiest to see in a real task. Adding open banking endpoints to a 1990s COBOL core means touching shared libraries that also handle settlement, which means a full regression cycle before anything ships. As a microservice, the open banking adapter is its own codebase with its own pipeline, and settlement is not in the blast radius. Most of our legacy core banking integration work lives at exactly that seam.

Banks typically end up with three layers: domain services for payments, accounts and lending; an integration layer holding the API gateway and the event bus; and a channel layer for mobile, web and branch. Sensedia S.A., an API management platform with banking clients, sits at the integration layer. Fimple, a cloud-native core banking vendor, represents the newer generation that ships the product as microservices from the start rather than retrofitting the pattern onto a legacy codebase.

Runtime choices from the 2015 to 2019 wave still shape what a bank runs today. Many programmes from that period were built on Jakarta EE containers, then still Java EE, which carried deployment weight that lighter runtimes such as Quarkus and Spring Boot later stripped out. Know which of the two a service was written for before estimating what it costs to move.

At the channel layer, low-code platforms do real work. OutSystems, founded in Lisbon in 2001 and now headquartered in Boston, is used by banks to build front-end services and workflow automation without writing every service by hand. That accelerates the layer where product teams iterate most, provided the domain service boundaries underneath it stay intact.

None of this is a binary choice. Most European banks run a hybrid: a microservices perimeter wrapped around a monolithic core, with decomposition expanding as the core is strangled out. That hybrid state is where the practical complexity lives, and it usually lasts longer than the programme plan says it will.

The organisational cost that architecture diagrams leave out

The technical diagram of a microservices deployment looks clean. Running one inside a regulated bank does not. Conway's law is the reason: a bank's software architecture mirrors its organisational structure. If the payments team and the accounts team share a deployment pipeline, they will eventually share a monolith, whatever the diagram says. Microservices need genuine team autonomy: separate pipelines, separate on-call rotations, separate budget lines. Decompose the software without decomposing the organisation and you get a distributed monolith, separate in name and coupled in deployment and data.

The overhead is concrete. Moving from one monolithic release a quarter to continuous deployment across forty services needs a platform engineering function that did not previously exist, with its own headcount and roadmap. Syntel, now part of Atos, built its financial services practice around that transition. Veltris and Atomic32 are part of the newer cohort banks engage for migration programmes, particularly strangler-fig work where legacy functionality is replaced piece by piece rather than in one cutover.

• team topologies aligned to service boundaries, not to the old departments
• a platform engineering function with its own budget line
• a centralised observability stack, in place before the service count grows
• an API governance policy with a named owner
• a service ownership register, kept current rather than rebuilt for audits

The regulatory dimension is not optional in the EU. Each service boundary is also a potential audit boundary: the bank has to show which service processed a transaction, which version was running and what its configuration was at the time. DORA Article 8 pushes the same way, requiring firms to identify and document their ICT-supported business functions and the dependencies between them, which the EBA's ICT and security risk management guidelines (EBA/GL/2019/04) already asked for. Distributed tracing is what makes that answerable, and it is a platform cost, not a service cost.

Where microservices deliver measurable value in banking, and where they do not

Not every banking function benefits equally from decomposition. A team that applies microservices uniformly across the estate, including the batch reconciliation that runs once a night and has not changed in a decade, spends engineering budget on complexity that returns nothing. The discipline is in knowing which capabilities justify the overhead.

Payments and real-time rails come first. ISO 20022 migration, instant payment schemes and open banking mandates all require message-handling logic to change without touching settlement. The T2 migration of 20 March 2023 made that concrete for every euro-area participant: a format change, on a fixed date, that had to reach the payment path and stop there. A versioned payments service can be rolled forward on its own. The same applies under the Instant Payments Regulation, where sending, receiving and verification of payee each moved on their own deadline.

Lending origination comes second. Pomelo Fintech Services SAS, in embedded finance and card issuing, is the standard example of a firm built on microservices launching credit products in weeks where a monolithic bank needs quarters. Wonderlend Hubs Private Limited shows the same shape in digital lending: decomposed origination, underwriting and disbursement services let a product change without a core release. Neither avoided the architecture cost. They paid it before they had a book to protect, which is the cheapest time.

Regulatory reporting comes third, and it is the argument that lands with a chief risk officer. A reporting service that subscribes to events from the domain layer can be updated for a new EBA template without the transaction engine being touched, tested or released. The reporting change stops being a core banking project.

The failure modes are equally consistent:

• distributed monolith: services deploy together and share a database, so the release risk of a monolith survives the migration
• data consistency gaps: each service owns its store, and nobody designed the compensation path for a half-completed flow
• observability debt: services are built faster than they are instrumented, and within eighteen months no one can trace a complaint across the mesh in under a day

The second one deserves a concrete case. A payment service debits one account, then the credit to the second account fails. There is no shared transaction to roll back, because the two services own different stores. The system needs a saga: an explicit compensating action that reverses the debit, an idempotency key so a retry cannot double it, and a record of the state the flow reached. Two-phase commit is the alternative, and it buys consistency with latency and a coordinator that becomes a single point of failure. Banks that skip this design step find out during a high-volume period, which is the worst time to design it.

Choosing vendors and platforms: what the procurement checklist misses

Vendor selection for a microservices programme usually evaluates API coverage, cloud compatibility and reference clients. It rarely evaluates what decides whether the programme survives at scale: how the vendor handles a service boundary change after go-live. Fimple is the useful reference point here, because a vendor shipping core banking as pre-decomposed services forces that argument into procurement, where boundaries are far cheaper to move than in production. Three questions get at it, and standard RFPs ask none of them.

1. What is the versioning and deprecation policy for APIs that our services depend on? A vendor that retires a version on six weeks' notice will cause a production incident, and the notice period belongs in the contract.
2. How does the platform handle schema evolution in event-driven services? If the payment event schema changes, either every consumer is updated in lockstep or the platform supports a schema registry with backward compatibility. There is no third option.
3. What is the observability contract? Does the platform propagate distributed tracing headers and emit its own spans, or does the bank instrument around a black box?

The answers cut both ways. OutSystems shortens the time to build a channel service and adds a dependency on a proprietary runtime, which belongs in the exit plan rather than in a later surprise. Sensedia's API management layer addresses versioning and the gateway head on. Jakarta EE is the reminder that platforms change hands: stewardship moved from Oracle to the Eclipse Foundation in 2017 and the specification was renamed the year after, mid-programme for anyone building on it. Under DORA this is no longer only good practice. Articles 28 to 30 require a register of ICT third-party arrangements and specific contractual terms, Article 29 asks whether an arrangement reinforces concentration risk, and the exit strategy has to be documented and tested rather than asserted.

Core and channel work we have shipped

Legacy core to modern digital banking, migratedProgressive banking super app, 1.5M+ installationsMobile banking app with a rebuilt user experience