Founder voice · 12 May 2026
Most Core Banking RFPs Solve the Wrong Problem.
After leading core banking selections at multiple regulated firms in Switzerland and the EU, the pattern is clear: the wrong platform isn't usually picked because the buyer chose badly. It's picked because the buyer asked the wrong question.
A core banking RFP that scores ledger features, payment rails, and API surface is solving a 2015 problem. The 2026 problem is regulatory composability: how cleanly can you bolt MiCA, DORA, PSD2, and PSR-1 evidence onto the same audit trail without forking the platform every time a regulator updates Article 28 or the RTS/ITS pack timeline. Most vendor demos optimise for the former because that's what RFPs ask. The institutions that hit production cleanly tend to ignore the demo and stress-test the latter against three live regulators in parallel.
The radar I publish at Finray Intelligence is structured for exactly this — 18 platforms scored across 16 criteria, with cloud-native architecture, microservice composability, and AI/ML extensibility weighted higher than feature breadth. Pure feature scoring loses to regulatory composability over a 7-year platform lifecycle. The radar is opinionated; that's the point.
If you're running a core banking selection at a PI, EMI, MiCA-authorised CASP, or a small/mid-tier bank — the radar is the version of this conversation that comes with vendor cross-links, RFP-domain mapping, and per-control evidence. Not a consultant's deck.