All insights
Whitepaper

Designing for Progressive Transformation in Retail Banking

An architecture rationale from FYNDNA

This paper is not a blueprint and does not claim to be a universal architecture. It sets out the practical decisions behind the way Fivolv is built, taken while running systems that were live, regulated and under load at the time. Every example in it is drawn from something already in production.

Length
32 pages
Read time
About 20 minutes
Written for
Chief architects, CIOs and core banking programme leads.
DownloadPDF, 13 MB

No form, no email address required.

Key takeaways

  1. 1Not everything in a bank changes at the same speedPosting transactions, maintaining balances, accounting and settlement should change as little as possible. Customers, products, pricing, onboarding, payment mechanisms, rules and limits change constantly. The trouble starts when the two are mixed, because then a pricing tweak means touching the core.
  2. 2Execution stays near the core. Business behaviour moves outCore product processors keep doing what they are best at. Everything that changes more often moves to an enterprise layer of capabilities defined once and reused, over a foundation layer of shared services. This does not replace existing cores. It protects them.
  3. 3Coexistence is assumed rather than avoidedEnterprise components talk to each other through events. Where an existing core can publish or consume events, they integrate that way; where it cannot, they work through controlled APIs and adapters. No core is re-engineered to make the model work.
  4. 4Change enters production a fraction of traffic at a timeAn insulation layer sits between changeable capabilities and stable downstream systems, so new behaviour starts on a very small share of live traffic and grows only as observation justifies it. Production stops being a final exam and becomes a controlled learning environment.
  5. 5A governor decides how much stress reaches stable systemsA dedicated control layer watches downstream health continuously and throttles incoming traffic when the core shows strain, so pressure is contained upstream instead of being pushed into systems that cannot absorb it. It is in place always, not just during incidents.
  6. 6Active-active is an operating posture, not a recovery planRegions serve traffic at the same time, deliberately more than 1,000km apart and on different cloud providers, so that one provider going down cannot take both. Failover and failback become controlled transitions rather than high-stress events.
  7. 7AI is kept out of the transaction pathPosting, pricing outcomes and eligibility decisions stay deterministic, rule-based and auditable. AI is applied in banker-facing and operational contexts, explaining how a fee was computed or summarising complex data for an authorised user, while the calculation itself remains deterministic and the decision stays with a person.
Download the paperPDF, 13 MB

Talk to the architects who wrote this.

The decisions in this paper were made against live traffic at a bank that could not go down. Tell us what your constraint is and we will go through how it applies.