- 1) Building without FCA sandbox or early FCA engagement
- 2) Missing PSD2 and Open Banking consent flows (and audit evidence)
- 3) No UK data location strategy (and assuming “AWS London” is a rule)
- 4) Weak Faster Payments and Bacs integration (or treating them as “later”)
- 5) No complaint logging and no DISP-ready process
- A quick pre-launch self-check
- Next step
Getting through the FCA gateway is not just “fill in the forms and wait.” For UK-facing neobanks, authorisation is where product decisions, controls, and operational readiness get stress-tested.
Even if the headline numbers you hear vary by definition, the trend is clear: a meaningful share of retail bank applications do not make it through the process as submitted. FCA data released via FOI shows rejection, withdrawal, and refusal (RWR) rates for retail bank authorisation applications ranging from 40% to 64% across 2020 to 2024. (FCA) The FCA also reports that “1 in 5” new firm applicants were not authorised in 2021/22, and highlights that incomplete and poor-quality applications are a persistent issue. (FCA)
This article breaks down five pre-launch mistakes that repeatedly derail UK fintech teams. Fix these early and you reduce rework, shorten timelines, and improve your odds of a clean FCA conversation.
1) Building without FCA sandbox or early FCA engagement
A common failure pattern looks like this:
You build a polished app, a sleek onboarding flow, and a “production-ready” roadmap. Then you discover that your testing plan, permissions strategy, and compliance controls are not aligned with how the FCA expects you to operate. The result is a painful reset: rewritten policies, reworked flows, and sometimes a revised business model.
The FCA’s Regulatory Sandbox exists for a reason: it is designed to help firms test innovative propositions with the right guardrails, and acceptance is based on clear criteria including readiness and need for support. (FCA) The sandbox is not mandatory, but ignoring early engagement can be expensive if your proposition needs controlled live testing or restricted permissions.
What “good” looks like before you build too far:
- A permissions map that matches your planned activities (what exactly you will do, when, and under which permissions)
- A testing plan that you could defend in front of a regulator, not just investors
- A clear approach to safeguarding, AML controls, and operational ownership
- A timeline that includes time for FCA questions and evidence gathering, not just development
If your strategy requires sandbox testing, use the FCA’s published eligibility criteria and application guidance as part of your planning, not as a last-minute checklist. (FCA)
How Finamp helps: Teams often use Finamp to validate a launch sequence that is regulator-ready from the start, so product scope, controls, and operational ownership align early instead of being patched right before submission.
2) Missing PSD2 and Open Banking consent flows (and audit evidence)
“Consent” in UK payments is not a UX label. It is an auditable flow with timing, revocation, and proof requirements.
Under the UK’s Payment Services Regulations (PSRs), consent must be clear, specific, and informed, and strong customer authentication (SCA) applies in relevant circumstances. (FCA) The FCA also highlights explicit consent expectations in Open Banking-related contexts, including scenarios where consent must be reconfirmed at least every 90 days (depending on the model and exemptions used). (FCA)
Where teams go wrong is treating consent like a pop-up rather than a system:
- No consent object stored (what exactly the customer agreed to)
- No consent expiry or re-consent mechanism
- No one-click revocation that stops data access and initiations promptly
- No evidence trail for when and how SCA and consent were applied
A clean PSD2 consent design usually includes:
- Consent capture: scope, purpose, duration, and the parties involved
- Consent lifecycle: status changes (active, expired, revoked) with timestamps
- Customer controls: view, renew, revoke
- Audit events: machine-readable records that you can hand to auditors or partners
If your MVP does not produce evidence, it does not exist in a regulatory conversation.
How Finamp helps: Platforms like Finamp can provide pre-built consent lifecycle patterns and audit-ready event logging, so you do not reinvent the mechanics that partners and regulators will scrutinise first.
3) No UK data location strategy (and assuming “AWS London” is a rule)
There is no single universal “AWS London requirement” published as a blanket FCA rule. The real problem is more practical: teams launch with unclear data location, unclear access rights, and unclear exit plans, then fail due diligence when asked basic questions like:
- Where is personal data stored and processed?
- Who can access it, including subcontractors?
- What happens if data becomes accessible outside the UK?
- How do you exit the provider safely?
The FCA’s cloud outsourcing guidance emphasises understanding and managing risk across the outsourcing lifecycle, including oversight and access expectations. (FCA) Separately, UK GDPR rules apply to international transfers and “restricted transfers” of personal information, including cases where data is made accessible outside the UK. (ico.org.uk)
A stronger approach is to build a simple “data residency strategy” that you can explain in one page:
- Data map: what data you collect, where it lives, which systems touch it
- Location controls: approved regions, environment separation, encryption and key handling
- Transfer logic: how you prevent or govern access from outside the UK where relevant
- Exit plan: how you migrate or terminate without breaking service continuity
Many UK fintech teams choose UK regions like AWS London because it simplifies conversations, but what regulators and partners really want is clarity, control, and evidence.
How Finamp helps: Finamp works with teams to define a realistic hosting and data location posture that satisfies partner due diligence while keeping architecture flexible for multi-market growth.
4) Weak Faster Payments and Bacs integration (or treating them as “later”)
UK customers and businesses do not tolerate a banking app that cannot reliably move money.
If your neobank cannot handle everyday payment expectations, you are not a bank in the user’s mind, and you will not look operationally ready in an authorisation or partner review.
Two rails matter early:
- Faster Payments (FPS): near real-time transfers, available 24/7/365, widely used for everyday bank-to-bank payments. (Pay.UK)
- Bacs: foundational for Direct Debit and Direct Credit, used for regular commitments like bills and for payroll-style payments. (Pay.UK)
A frequent pre-launch mistake is building a UI for “transfers” without designing the operational reality:
- payment status tracking (pending, accepted, rejected, returned)
- retries and reconciliation
- customer notifications that reflect the true state of the payment
- handling of cut-offs and scheme-specific behaviours
- support playbooks for common failure modes
Founders who prioritise FCA readiness treat payments as an end-to-end service, not a feature. That means aligning product flows, support scripts, and backend observability before a regulator or sponsor bank asks, “What happens when this fails?”
How Finamp helps: Finamp can accelerate scheme-ready payment experiences by providing proven integration patterns and operational tooling, so your product is not blocked by hidden complexities in UK rails.
5) No complaint logging and no DISP-ready process
This is one of the most avoidable mistakes, and it signals immaturity instantly.
The FCA Handbook’s DISP rules require firms to keep records of each complaint and also set expectations around complaint reporting (including regular reporting to the FCA in applicable cases). (handbook.fca.org.uk) The point is not bureaucracy. The point is evidence that you can treat customers fairly, identify root causes, and improve.
What FCA-ready complaint handling looks like in an MVP:
- A complaint register: each complaint logged with category, product area, timestamps, and resolution outcome
- Clear ownership: who investigates, who signs off, who escalates
- Evidence trail: supporting data, communications, decisions
- Management information: trend reporting that feeds product and risk fixes
- Customer outcomes: acknowledgement, timelines, and final response processes
If you are building a neobank, complaint handling cannot be a shared inbox. It must be a system.
How Finamp helps: Finamp supports an operational model where compliance-facing workflows (like complaint capture and reporting readiness) are designed as part of launch, not retrofitted after the first incident.
A quick pre-launch self-check
If you want a fast diagnostic before you talk to partners or prepare an FCA submission, ask five questions:
- Can we explain our permissions and testing plan in one page, and does it match what we have built?
- Do we have PSD2 consent flows with expiry, renewal, revocation, and audit events?
- Can we prove where data is stored, who can access it, and how we manage UK GDPR transfer risk?
- Do Faster Payments and Bacs behave correctly end-to-end, including status, reconciliation, and support workflows?
- Do we have a DISP-ready complaint register and a process that produces evidence?
If any answer is “not really,” that gap will show up later, usually when time is already expensive.
Next step
If you are building a UK neobank MVP and want to reduce FCA approval risk before you spend months building the wrong thing, Finamp can help you map a regulator-ready launch sequence. That includes the “unsexy” parts most teams underestimate: consent evidence, payment rail realities, data location controls, and complaint handling readiness.