Digital product engineering · Banking
Core banking integration and API layer
We build core banking integration and API layers that let banks launch digital products without rewriting the core: an anti-corruption layer that hides the core's formats, event streaming for changes, an API gateway for channels and partners, and adapters for batch files and legacy messages. It makes an old core look like a modern platform to everything around it, and you own the code.
Checklist · Payments
Payment hub and ISO 20022 readiness checklist
A checklist for banks and payment firms planning a payment hub, a real-time payments connection or an ISO 20022 migration: formats, mapping, validation, routing, exceptions, reconciliation and resilience.- 01Eight areas to review before you choose or build a payment platform.
- 02The message and data points that cause rejections: addresses, identifiers and remittance data.
- 03Questions on cut-offs, liquidity and exception handling.
- 04Seven questions to put to any vendor or development partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Anti-corruption layer
A translation layer that maps the core's data and codes into a clean domain model, so channels and new services never depend on legacy formats. - 02
Domain APIs
Customer, account, balance, transaction, payment and product APIs with stable contracts and versioning, independent of the core's release cycle. - 03
API gateway and developer portal
Authentication, rate limiting, quotas and analytics for internal channels and external partners, with a portal and sandbox for developers. - 04
Event streaming
Core changes captured and published as events, so downstream systems react in near real time instead of polling or waiting for overnight files. - 05
Change data capture
Reading changes from the core's database or journal without adding load to online transactions, with an outbox pattern where the core can be changed. - 06
Batch and file adapters
Scheduled and on-demand exchange of files with the core, with validation, acknowledgements and re-run safety. - 07
Transaction orchestration
Multi-step operations spanning the core and other systems, with compensating actions when one step fails, so accounts are never left half-updated. - 08
Caching and read models
Read-optimised stores for balances and statements that protect the core from channel traffic and survive core downtime. - 09
Monitoring and traceability
End-to-end tracing of each call across channel, layer and core, with alerts on latency, errors and reconciliation differences.
Reference architecture.
Standards and interfaces
What we design against.
- OpenAPI and AsyncAPI
- Contracts for synchronous APIs and for the events the layer publishes, kept in version control.
- Open banking API standards
- The HKMA Open API Framework, UK Open Banking, Berlin Group and similar standards, as the model for externally facing APIs.
- OAuth 2.0, OpenID Connect and FAPI
- Authentication and authorisation for customers and partners, with the financial-grade profile for high-risk APIs.
- ISO 20022 and ISO 8583
- Payment messages and card messages that the layer translates to and from the domain model.
- Messaging and streaming
- Message queues and log-based streaming platforms for events and reliable delivery.
- Supervisory expectations
- Technology risk, outsourcing and operational resilience guidance that shapes testing, change control and recovery.
Data model
The core entities.
- Customer and party
- A single customer view mapped from the core's customer records, with identifiers for each system.
- Account and balance
- Account attributes, balances and holds in the form channels expect, with the source timestamp.
- Transaction
- Normalised entries and their link to the originating payment or message.
- Product and condition
- Product definitions, rates, fees and limits exposed to channels.
- Event
- Type, payload, source, time and delivery status for each published change.
- Mapping rule
- Core field, domain field, transformation, version and owner.
- Client and consent
- Partner applications, scopes granted, customer consent and revocation.
When custom development is the right call.
Controls designed in, not added later.
Zero trust between services
Mutual authentication, scoped tokens and least-privilege access between every component.Consent and scopes
Third-party access only within the scopes a customer granted, with revocation honoured immediately.Protection of the core
Rate limits, bulkheads and circuit breakers so channel traffic cannot degrade core processing.Idempotency and integrity
Request keys and signed events, so repeated or replayed calls have no extra effect.Auditability
Every call and event carries a trace identifier from channel to core and back.
From discovery to a system you run.
- 01
Landscape and interface survey
We list the core's interfaces, batch jobs and data stores, and the channels and partners that need them. - 02
Domain model and API design
The domain model and API contracts are agreed with channel and core teams, with the mapping to the core documented. - 03
Build the first domains
Customer, account and balance usually come first, then payments and products, each with contract tests against the core test system. - 04
Strangler migration
Channels move onto the layer one by one, so direct core calls shrink until they are gone. - 05
Operate and extend
New products, partners and events are added through the layer, with versioning and a deprecation policy.
Relevant work
Where to see our work.
Common questions.
- Do we need to replace our core banking system first?
- No. The integration layer is often the way to avoid it, or to make a later core replacement safe, because channels depend on stable APIs and not on the core.
- How do you read from a core that has no API?
- Through its database or journal using change data capture, through batch files and messages it already produces, or through a thin adapter. Each option is chosen to keep load off the core's online processing.
- What happens if the core is down?
- Read models serve balances and statements from the last known state, flagged as such, and writes queue or fail cleanly according to the product's rules, with reconciliation when the core returns.
- Can we expose APIs to partners and fintechs?
- Yes. The gateway handles partner onboarding, scopes, consent and rate limits, and a sandbox lets partners test before they go live.
- Who owns the code?
- You do. The code, the mappings and the data stay yours.