If your product holds customer money, shapes an investment decision or runs under an FCA permission, the review will ask the software to prove things about itself long after anyone remembers building them. Firms rarely fail on what the product does. They fail on what it cannot show.
✓ Built to your compliance function's interpretation · Never a substitute for it
Your compliance function decides what the rules require of your firm. The build has a narrower job: making the product demonstrate it, on request, to someone who was not in the room when it was designed.
Every action in the product maps to a regulated activity the firm holds a permission for. Anything outside that boundary is absent from the build a customer can reach. A feature flag is a policy with a switch on it, and somebody can always flip the switch.
The inputs, the rule set and the version of the logic behind an outcome are stored together. When someone asks what the system would have said on a given day, the answer comes from the record, with no developer reconstructing it from memory.
Balances are derived from a ledger of movements, so every pound carries its own history. Reconciliation, which the client money rules in CASS expect you to perform and evidence, becomes a property of the data model instead of a spreadsheet assembled later.
Decisions are logged with their inputs and the rule version applied, kept for as long as your record-keeping obligations require, and readable by someone in compliance. A log that only an engineer can read leaves the firm unable to answer its own regulator.
Four of these apply on every gate we work in. The fifth is particular to financial services, and it protects you as much as us. Each one is easier to hear now than in month three.
None of these is a bug. The product does exactly what it was asked to do. Nobody asked it to explain itself afterwards, and a reviewer reads that silence as a gap.
Logging arrives near launch, which is like fitting the flight recorder after the plane has landed. The product worked perfectly for six months, and the evidence for those six months does not exist.
Permissions are written into a policy and enforced by everyone remembering them. A reviewer asks to see the limit inside the product, and there is nothing on screen to point at.
A balance is a field that gets overwritten. Reconciliation cannot be demonstrated, and every correction erases the history behind it, which is the one thing a client money review wants to read.
The suitability logic changed three times in a year and nothing recorded which version applied to which customer. Explaining a past outcome now means reconstructing old code.
This is the FCA version of the Week-One Review. It starts from what the product will have to demonstrate, then tests whether the current plan can demonstrate it. A founder leads the week, because the sequencing decisions made in it cannot be delegated.
Day 1 · Name the permissions in play and the person who signs the submission
Day 2 · List what the review will expect the product itself to evidence
Day 3 · Test the data model against reconciliation and audit questions
Day 4 · Decide the sequence, and the features cut from version one
Day 5 · Price it: the build sequence, the risks and a fixed quote
5 days
The fee is quoted before you start and credited against the build when you proceed.
They are yours whether or not you build with us, and they work in another supplier's hands too.
Gather is a multi-currency retail investment platform that combines investing with learning, wellbeing and community. Retail investment leaves little room for error. The product holds customer money, and every screen that shapes an investment decision has to stand up after the customer has forgotten seeing it.
So the usual order of work was inverted. Permissions, the ledger model and the audit trail were settled before the interface, and the evidence became a by-product of building instead of a reconstruction at the end. A deliberately narrow first version meant fewer screens to defend.
The platform opens at a £30 minimum entry, which puts regulated investing within reach of people who would never clear a four-figure threshold.
£30
Minimum investment entry
The loading pays for three things an ordinary quote leaves out: evidence produced while the build runs, documentation a reviewer can follow, and time held back for findings.
Most FCA work starts at Band 2, because the ledger, the audit trail and the evidence pack belong in the first version. Where a firm is already authorised and the product surface is narrow, Band 1 can be enough. The Week-One Review tells you which of those you are before you commit to either.
Quoted after the Week-One Review
All six are about building the product. Regulatory advice stays with your compliance function, and every answer below keeps to that line.
No. We build to the interpretation your compliance consultant, in-house team or solicitor gives us. Where it is unclear, or two of them disagree, we flag it and wait for their decision instead of making it for you.
Yes, provided the boundaries between systems can be evidenced. Banking partners, custodians, brokers and existing ledgers stay where they are, and keeping them usually costs less than replacing them.
Less than most teams fear, in a form most teams have not built: the inputs to a decision, the rule version applied, the outcome, and the time of each, retrievable without a developer writing a query. Produce that and most of the rest is paperwork.
It changes who signs and what your principal firm will want to see, more than it changes the architecture. The principal carries regulatory responsibility for you, so the evidence it asks for looks a lot like the evidence the FCA would ask for.
As a scoped piece of work, provided the first build enforced the permission boundary in one place. That is why we care where permissions live in version one, even when the firm holds a single set of them.
Your compliance function translates the rulebook into requirements, and we build to those. Hand an engineering team a raw rulebook reference and expect an architecture back, and you get a product that is defensible on paper and awkward in practice.
Those two answers set the ledger design, the audit trail and how narrow version one has to be. Almost everything else in a build can be negotiated. Those two cannot. If a bank partner's security review applies as well, the regulated software page covers both of those gates.
NOT REGULATORY ADVICE / BUILT TO YOUR COMPLIANCE FUNCTION'S INTERPRETATION