Core Banking Modernization

The Strangler Fig Pattern is an incremental migration approach where new services are built alongside the existing system rather than replacing it all at once. Each new microservice takes ownership of one domain, account queries, transaction lookups, and balance checks, while the legacy system continues handling everything else. Over time, the legacy system's responsibilities shrink until it is either fully replaced or isolated to a minimal footprint. In core banking, this approach is used because a big-bang replacement requires a cutover window where the system is unavailable. For a bank processing live transactions, that window is not acceptable.

The OBP Proxy Service handles all translation between the legacy SOAP/XML interface and the gRPC layer that the new microservices use. Existing integrations that already speak SOAP continue to work unchanged — they communicate with the proxy, which translates their requests and routes them appropriately. New services built on gRPC never interact with SOAP directly. The translation boundary is maintained in one place, which makes it auditable and testable.

It means the production system remains live and serving real user traffic throughout the entire migration. There is no scheduled maintenance window during which the banking app goes offline. Traffic shadowing is used to validate new microservices: a copy of live traffic is sent to the new service in parallel with the existing one, and the outputs are compared before the new service takes over. Only after validation does traffic shift.

TTL values are set per data type based on its update frequency and its tolerance for staleness. Balance data — which changes on every transaction — has a short TTL or is invalidated on write. Reference data — product terms, branch details — has a longer TTL because it changes infrequently. Session data is scoped to the session lifetime. Caching is not applied uniformly; it is tuned to the consistency requirements of each domain.

No. Audit trail continuity is a specific requirement built into the architecture. The Golang microservices maintain the same audit logging as the legacy system. Regulatory reporting is not disrupted during the migration or after it.

Scope determines timeline. A single-domain modernization — wrapping one OBP service boundary in a Golang microservice with Redis caching and gRPC — can be delivered in eight to twelve weeks. Full platform modernization across multiple domains runs longer and is typically phased, with each phase delivering production-live services before the next begins.

The Strangler Fig Pattern and the Golang wrapper approach are not specific to OBP or FlexCube. The feasibility with other platforms depends on the API surface available for integration. We assess this during the discovery phase.

The system is handed over production-ready, benchmarked, and documented. Your team can maintain and extend it independently. We do not build on proprietary frameworks that require ongoing vendor involvement to operate. If your team wants a formal support arrangement post-launch, that is a separate conversation.