Signs Your Fintech Build Was Never Designed for an FCA Review

Most fintech teams find out their build cannot answer a reviewer's questions at the worst possible moment. The signs were there months earlier, in decisions nobody flagged as compliance decisions.

The evidence problem is already in the data model

• Balances are stored as a single field that gets overwritten on each change. If nobody can trace how a figure arrived at its current value, the client money question has no answer that does not involve rebuilding history.
• Logging is treated as a launch task. Ask yourself when the first line of audit logging was written. If the honest answer is "near the end", the months before it are a blank.
• Rules live in code with no version attached. Suitability logic that changed three times in a year, with nothing recording which version produced which outcome, turns a simple question into an archaeology project.
• The audit records exist but only an engineer can read them. A compliance officer who needs a developer to interpret a log is a firm that cannot answer its own regulator promptly.

The permission boundary is a document, not a feature

• Someone can describe the firm's permissions from memory, but nobody can point to where the product enforces them.
• A feature flag is doing the work of a permission boundary. Flags are policy with a switch, and switches get flipped by people who were not in the room when the rule was agreed.
• Features exist in the customer-facing build that no permission clearly covers. The usual justification is that nobody uses them yet.
• The person who signs the submission has never been shown the product. If that name is unfamiliar to the engineering team, the sequencing decisions are being made without the person who carries the risk.

The plan assumes the review happens after the build

• The roadmap has a launch date and a separate, later line for compliance. A build sequenced forwards from features rather than backwards from a submission date tends to discover its gaps when there is no time left to close them.
• Scope was set by what customers asked for, not by what the product will have to demonstrate. Those two lists are rarely the same, and the difference is where version one quietly grows.
• The team expects to handle the review later. Ask what would have to be true for the current build to prove its behaviour for the last six months. If the answer is "nothing can", the timing is the problem.
• Nobody has asked whether the product needs authorisation at all, or which permission covers it. That is a legal question, not an engineering one, and it belongs with a regulatory lawyer or compliance consultant before anyone scopes a build.

A good outcome is unglamorous. The product can show, on request, that a customer only did what the permissions allow, that a past decision can be explained from the record, and that money movements carry their own history. None of that is visible in a demo, which is exactly why it gets deferred.

If several of these feel familiar, the useful next step is understanding what the review will actually expect the software to prove, and what a build sequenced from that looks like. The full guide on FCA regulated software development sets out the four things a review expects the product to evidence, the five project types worth declining before the first call, and the week-one review that settles the audit and reconciliation model before any schema work begins.