Core Banking
Core banking succeeds at the boundaries
The most difficult part of a core transformation is rarely the ledger.
The ledger gets most of the attention in a core banking transformation. In my experience, the hardest work sits around it: identity, product configuration, payment orchestration, migration, reporting and the dozens of assumptions exchanged between organisations.
Interfaces carry organisational assumptions
An API contract describes fields and status codes. It rarely captures who is allowed to retry, which system owns the customer state, or how a correction appears in reporting. Those are operating-model questions disguised as integration detail.
During onboarding I push for boundary maps before build plans. For each journey we identify the system of record, synchronisation pattern, failure owner, reconciliation method and customer-facing consequence. That exercise exposes disagreements while they are still cheap to resolve.
Migration is a product journey
Migration is often handled as a technical transfer. Customers experience it as continuity: balances, mandates, statements and access must remain coherent before and after the cutover. A perfect row count is necessary, but not sufficient.
I prefer progressive evidence—sample migrations, reconciliation at each stage, business sign-off on exceptions and an explicit fallback point. The plan must explain not just how data moves, but how confidence is earned.
Keep the core boring
A healthy architecture protects the ledger from channel-specific logic and short-lived integrations. The boundary layer translates, validates and absorbs change, while the core remains consistent.
That is not an argument for endless middleware. It is an argument for intentional ownership. Every abstraction has an operational cost, so it should remove more ambiguity than it creates.