Integrating a Core Banking Platform Into an Existing Payments Stack
CLIENT
A US-based financial services company processing several billion dollars in payment volume annually. The organization operates a mix of proprietary payment rails and third-party processor integrations, and serves both retail banking customers and enterprise clients through a shared platform. The engineering team had around 90 people at the time of engagement.
CHALLENGE
The client needed to integrate a new core banking system alongside their existing payment processing infrastructure. The original ask was straightforward: build the integration layer. They had a vendor selected, a timeline in mind, and budget approved.
The request came to us because we had done previous work on their data pipeline, specifically a project that had cleaned up how transaction records moved between internal systems and external reporting tools.
The team trusted us with the new work and wanted to move quickly. We asked for two weeks before touching any code.
SOLUTION
The discovery phase covered the existing payment infrastructure in detail: how transactions flowed from initiation through settlement, where the current system’s integration points were, what the new core banking vendor’s API surface looked like, and what the compliance and audit requirements were for any changes touching payment processing.
Two things surfaced early that changed the shape of the project.
The first was a settlement timing mismatch. The new core banking system operated on a near-real-time settlement model. The existing infrastructure was built around batch processing with end-of-day reconciliation. These two approaches were not compatible at the integration layer without a buffer component that neither the client nor the vendor had planned for. Building without it would have created reconciliation gaps that wouldn’t have surfaced until production.
The second was a regulatory constraint the client’s legal team had flagged internally but hadn’t communicated to the engineering team. Certain transaction types, specifically cross-border payments above a threshold, required a logging format that the vendor’s standard API didn’t produce. The vendor had a compliant output mode, but it was not enabled by default and required a separate configuration agreement.
We brought both findings to the CTO and the project sponsor. The original timeline was eight weeks. With the buffer component and the vendor configuration work factored in, a realistic timeline was fourteen weeks. We also flagged that trying to hit eight weeks and patching the reconciliation issue later would cost more than doing it correctly now.
The project sponsor pushed back on the timeline. The conversation was direct: we explained what would be in production if we cut corners, and they made the call to extend.
The build covered four areas: a transaction buffer layer normalizing settlement timing between the two systems; a compliance logging module with automated validation before records were written; an event-driven reconciliation process reducing the window from end-of-day to under fifteen minutes; and a rollback mechanism allowing individual transaction types to be rerouted back to the legacy path without a full deployment.
RESULT
TECHNOLOGY STACK
– Java + Spring Boot — core integration services and transaction buffer layer
– Apache Kafka — event-driven transaction flow between legacy and new core banking systems
– PostgreSQL — reconciliation state and compliance log persistence
– AWS Lambda + SQS — asynchronous processing for high-compliance transaction types
– AWS CloudWatch + PagerDuty — alerting on reconciliation gaps and settlement anomalies
– Terraform — infrastructure as code across all integration components
– Vault by HashiCorp — secrets management for API credentials across vendor and internal systems
The integration went live at week fifteen, one week past the revised estimate due to a configuration delay on the vendor’s side.
The reconciliation window dropped from end-of-day to under twelve minutes. The compliance team ran an internal audit two weeks after go-live and found no gaps.
The rollback mechanism was used once in the first three months. Not because of a critical failure, but because one transaction type had edge-case behavior in production that hadn’t appeared in testing. The team rerouted it in under ten minutes, fixed the issue, and re-enabled it the same day.
The CTO noted afterward that the settlement timing issue alone, had it gone undetected, would likely have required an emergency remediation costing more than the entire project.
The client subsequently asked us to scope the next phase: extending the same integration pattern to their enterprise payment clients, who operated under different SLA requirements.
Share:
