Signs Your Fintech Build Will Struggle at the FCA Review

• The Evidence Arrives Last
• The Boundary Lives Outside the Build
• Money Is Modelled as a Number
• Questions Worth Sitting With

A working product can still fail a review, because the reviewer is not testing whether it works. They are testing whether it can account for itself. These are the symptoms that usually predict trouble.

§The Evidence Arrives Last

• Logging is still on a backlog item, and the launch date is the one being defended.
• Nobody can say what the product would have recorded for a customer six months ago, because it was not recording anything.
• The audit trail exists, but only an engineer can read it, which leaves compliance unable to answer its own regulator without help.
• When asked why a customer saw a particular screen on a particular date, the honest answer involves someone opening old code.

§The Boundary Lives Outside the Build

• Permissions are described in a policy document, and enforcement depends on the team remembering what the document says.
• A feature flag is doing the work of a permission, and everyone knows a flag can be flipped by someone who was not in the room.
• There is a customer-reachable path to a capability the firm has no permission for, and it survives because nobody has looked for it.
• When a reviewer asks to see the limit inside the product, the answer is a link to a wiki page rather than a screen.
• The rules that decide suitability have changed more than once, and no record says which version applied to which customer.

§Money Is Modelled as a Number

• A balance is a field that gets overwritten, so each correction quietly erases the history behind it.
• Reconciliation is a spreadsheet assembled after the fact rather than a property of the data model.
• Asked to prove separation on a given day, the team would need to rebuild the state rather than read it.
• Client money logic was written by people who never saw the CASS expectations it has to satisfy, and it shows in the shape of the data.
• The build sequence was set by feature demand, and the submission date was added at the end rather than designed backwards from.

§Questions Worth Sitting With

• Which permission does each action in the product map to, and who can point to the line of software that enforces it?
• If a reviewer asked for last March’s evidence tomorrow, how much of it exists without an engineering project?
• Who signs the submission, and have they seen the data model rather than the roadmap?
• What was deliberately left out of version one, and is there a written reason for each omission?
• Has anyone confirmed the authorisation question with a regulatory lawyer rather than with the build team? That is a legal judgment, not an engineering one.

None of these are bugs. The software does what it was asked to do. The gap is that nobody asked it to explain itself later, and a reviewer reads that silence as a failure. A good result looks unremarkable from the outside: evidence that already exists, a boundary a customer cannot cross, and money whose history survives every correction.

The full guide sets out what the review expects the product to prove and how a build is sequenced backwards from it: FCA regulated software development for UK fintechs.