Insights
What we have learned building in production.
Not positioning papers. These set out the architectural decisions behind Fivolv and the engineering behind the data layer, written from systems that were live, regulated and under load at the time. Both are free to read and there is no form in the way.
Designing for Progressive Transformation in Retail Banking
An architecture rationale from FYNDNA
Why banking systems look the way they do, and what changes when you stop trying to replace them. Keep execution stable near the core, move business behaviour out to the enterprise and foundation layers, and introduce change under live traffic rather than on a cutover date.
Banking at Scale
Ultra-resilient core banking on YugabyteDB and FYNDNA's cloud-native platform
What the data layer has to do when payments run at thousands of transactions per second and the platform has to survive a region, or a whole cloud provider, going down. Active-active across GCP and AWS, database upgrades performed in production, and measured results per component.
Every figure in these papers came out of a running system.
The architecture described in them is the one running the payments, customer, pricing and continuity components at one of the world's largest banks by market capitalisation. If something in either paper is relevant to a decision you are making, we are happy to go through it with your architects.
Read the paper, then talk to the people who wrote it.
The architects who made these decisions are the ones you would be working with. Tell us which part of your core is hardest to change and we will go through how this applies to it.