Fast track your fintech app through regulatory hurdles

Regulatory compliance in fintech is a design constraint that shapes every architectural decision from the first sprint, and teams that treat it as an afterthought tend to discover this the expensive way. We learned that lesson directly on a peer-to-peer currency exchange product, where users could swap leftover foreign currency with fellow travellers at interbank rates, bypassing bank and bureau fees entirely. The core transfer mechanism worked well.

What we did not factor in was anti-money laundering requirements, and Apple flagged the product as a potential vehicle for money laundering because of its unlimited transfer capability. We had to go back and retrofit more stringent KYC checks, enhanced transfer security, and hard limits on the number of transfers permitted between any two parties.

Compliance built in from the start shapes a better product. Compliance bolted on reshapes it badly.

That retrofit did not just cost time and money. It changed the product's character. Features that had felt light and frictionless suddenly carried visible compliance machinery, and the experience of rebuilding existing code to accommodate new constraints is harder than building those constraints in from the start. The peer-to-peer product ultimately did not survive to launch, and regulatory pressure was a significant part of the reason.

What follows draws directly from that project, and from several others where regulatory requirements arrived late, arrived from unexpected directions, or arrived in the form of App Store rejection rather than a letter from a regulator. The patterns are consistent enough to be worth mapping before you write a single line of code.

Why Compliance Delays Compound

A single compliance gap, found late, does not produce a proportionate delay. It produces a cascading one. When a regulator or platform flags an issue after build, the team must stop forward development, diagnose the root cause, redesign the affected flows, rebuild them, retest, and then resubmit. Each of those stages takes time, and the time is rarely sequential because the people needed for one stage are often blocked by another. Meanwhile, the rest of the product is frozen.

The compounding effect is worse in fintech than in most other categories because financial products carry more interdependencies. AML requirements affect onboarding, transfer flows, and limits. KYC checks affect identity verification, which affects how the app handles repeat users, which affects your data model. Pull one thread and several others move. According to GoodFirms, highly regulated industries like fintech can see development budgets increase by 30 to 50 percent due to compliance, security, and data protection requirements. That figure reflects the cost of getting it right. Getting it wrong and rebuilding costs more still.

The real problem is that compliance delays tend to arrive at the worst possible moment: after the team has built confidence in a feature, after stakeholders have aligned on a timeline, and often after external commitments have been made. At that point, the conversation about whether to build compliance in properly or ship a workaround becomes genuinely difficult, and workarounds in regulated products have a habit of becoming permanent.

The Regulatory Landscape Fintech Apps Actually Face

Fintech apps do not answer to one regulator. They answer to several simultaneously, each with a different scope, a different enforcement mechanism, and a different appetite for interpretation. Understanding which bodies apply to your product is the first piece of work, and it is not always obvious.

Financial regulators and platform policies

In the UK, the Financial Conduct Authority governs most consumer-facing financial services, from payment initiation to investment products. If your app touches payments, lending, or currency exchange, FCA authorisation or a relevant exemption is likely required before you can operate. Separately, GDPR governs how you handle personal and financial data, and the requirements there have direct implications for onboarding design, data retention, and user consent flows.

AML, KYC, and transfer rules

Anti-money laundering regulations impose specific obligations around customer verification and transaction monitoring. These are legal requirements that carry criminal liability if ignored. Know Your Customer checks must be designed into onboarding from the start, because retrofitting them later forces a redesign of flows that users have already experienced. Transfer limits, flagging thresholds, and reporting obligations all follow from AML and must be reflected in the product's architecture before build begins.

The regulatory landscape also changes. Rules that applied at the start of a project may be updated before launch, which is why designing for adaptability matters as much as designing for current compliance.

When AML Requirements Are an Afterthought

On the peer-to-peer currency exchange project, AML was not part of the initial design brief. The product's appeal was its simplicity: two people with leftover currency, a direct exchange at interbank rates, no fees, no intermediaries. That simplicity was also what made it attractive to Apple's fraud detection, because an unlimited peer-to-peer money transfer product with minimal identity verification is structurally indistinguishable from a money laundering tool.

We had to go back and add more stringent KYC checks than the original design had anticipated, layer in enhanced transfer security, and physically limit the number of transfers permitted between any two parties. Each of those additions was architecturally disruptive because the original flows had not been built to accommodate them. The experience of retrofitting compliance onto existing code is genuinely harder than building it in from the start, particularly when the compliance requirements touch the core user journey rather than peripheral settings screens.

AML requirements are not a peripheral feature. They sit at the centre of every transfer flow.

The practical lesson is that AML requirements should be documented at discovery, mapped against every flow that involves value transfer, and treated as a fixed constraint rather than a feature to be scoped later. If your product moves money between people, AML is not a compliance add-on: it is part of the product's core logic.

Map every flow that involves value transfer at discovery stage. For each one, identify what AML obligations apply, what KYC data is required, and what transfer limits must be enforced. Doing this before wireframes saves significant rework later.

App Store Policies Are a Compliance Layer Too

Apple's App Store review process operates as a separate compliance layer from financial regulation, and it does not always move in the same direction. A product can be fully FCA-authorised and still be rejected by Apple. The reverse is also possible, though less common in fintech.

On the currency exchange project, the app was rejected by Apple repeatedly. Each time we addressed Apple's stated objection, a new one appeared. Apple eventually cited the potential for money laundering and criminal activity. We capped transactions at €150, which should have addressed those concerns directly. Apple rejected the app again. The client ran out of budget and abandoned the product. It later became apparent that this period coincided with the build-up to Apple Pay's launch, which suggested the rejections were strategically motivated rather than genuinely compliance-based.

Apple's review process has no effective mechanism for a developer to challenge iterative rejection. A well-funded incumbent can effectively block a compliant competitor from reaching the market by raising successive new objections each time the previous one is resolved. This is not a theoretical risk. We experienced it directly, and the cost to the client in legal counsel, compliance work, and lost development time was substantial.

Before committing significant development budget on a fintech product, run a pre-submission review against current App Store guidelines for financial services. Pay particular attention to sections covering money transfer, peer-to-peer payments, and currency exchange. What Apple permits changes, and often without announcement.

How Payment Provider Constraints Shape Your Architecture

Choosing a payment provider is often treated as a technical integration task. The provider's constraints, however, shape product architecture in ways that become very difficult to reverse once build has started.

When we integrated Stripe Connect on a project requiring delayed payouts to simulate escrow behaviour, we found that different Stripe account types impose significantly different constraints. Express accounts require near-immediate payouts, which did not suit the use case. Moving to a different account type gave us the control we needed over payment timing, but the integration complexity increased considerably. The challenge was finding the balance between the precise payment behaviour the product required and the level of customisation that would cause us to lose the benefits of Stripe's default payment handling.

Payout timing and escrow behaviour

If your product needs to hold funds before releasing them, which covers anything resembling escrow, marketplace payments, or conditional transfers, you need to know your payment provider's position on this before you design the payment flow. Some providers restrict this by account type. Others require additional verification. Some prohibit it for certain product categories.

Geographic and currency restrictions

Payment providers also apply geographic restrictions that may not be obvious from their documentation. Currency support, supported countries, and the regulatory authorisations a provider holds in each market all affect what your product can actually do. A feature that works in one market may not be available in another, and discovering this late forces either a feature compromise or a provider switch, both of which are expensive.

Retrofitting Compliance Costs More Than Building It In

According to Globalscape's data protection research, the cost of non-compliance runs at nearly three times the cost of compliance. That ratio maps closely to what we see in practice when comparing projects that built compliance in from discovery against those that addressed it reactively.

The dating app project illustrates the same principle in a slightly different context. The client chose to skip discovery for the messaging component and focus purely on onboarding. The result was a generic messaging feature that allowed automated and fake messages, which directly contradicted the core product premise of verified, bot-free profiles. The entire messaging section had to be rewritten, costing approximately £15,000 in additional budget and two months of extra work. The discovery that was skipped would have cost a fraction of that and would have caught the contradiction before a line of code was written.

In fintech specifically, the retrofitting problem is more acute because compliance requirements touch so many interdependent parts of the product. Adding KYC after build means revisiting onboarding, identity storage, verification flows, and error states. Adding transfer limits means revisiting the transfer architecture, the UI, and the messaging around why a limit exists. Each addition creates regression risk in features that were already tested and signed off.

Run a compliance audit of your user journey at wireframe stage, before any high-fidelity design begins. Identify every point where the product requests something from the user or moves value between parties. Those are the points where regulatory requirements are most likely to force a redesign.

Designing for Regulatory Pivots Before They Are Forced on You

The peer-to-peer currency exchange product we worked on required a fundamental pivot partway through the project. We discovered that both legal regulations and Apple's App Store policies prohibited direct remote peer-to-peer payment transfers of the kind the product had been designed around. The product had to become location-based and in-person: users would meet up and physically exchange currency rather than transacting remotely. That pivot changed everything from the core UX model to the map-based interface to the safety features required for in-person meetups.

A pivot forced by an external constraint is harder to absorb than a pivot made by choice, because the team has already built confidence in the original direction and the existing code reflects assumptions that no longer hold. The fitness social app we worked on faced a similar moment when research revealed that a high proportion of users were female, making precise real-time location sharing a significant security concern. The team redesigned the feature to introduce randomised location offsets, so users could see only the vague area where a potential workout partner was located, with exact location shared only after both parties had reviewed each other's profiles and consented.

That kind of pivot is manageable when it happens at research stage. The same pivot at late build stage would have been much more disruptive. Designing for the possibility of regulatory or platform-driven change means building product architecture that can absorb a change in the rules without requiring a full rebuild. This is a concrete architectural requirement, not a philosophical one.

Building a Compliance-First Discovery Process

Discovery for a fintech product should include regulatory mapping as a first-class deliverable, not an appendix. That means identifying the applicable regulatory bodies before wireframes begin, mapping the specific obligations that apply to each product flow, and documenting the constraints that each obligation creates for the design and architecture.

The questions worth asking at discovery stage fall into a consistent pattern across fintech projects.

1. Which regulatory bodies apply to this product, and in which markets?
2. What authorisations or exemptions are required before the product can operate?
3. Which flows involve value transfer, and what AML and KYC obligations apply to each?
4. What data does compliance require us to collect, store, and report?
5. What are the App Store policies for financial services in our category, and have we reviewed recent rejection patterns?
6. What payment provider will we use, and what constraints does their account structure impose?

These questions do not need to be answered by a legal team before any design work begins, but they need to be on the table. The Spotify-to-Deezer switch on the memory-sharing proof-of-concept project is a useful reference point here: moving to Deezer's official API simplified both the technical architecture and the compliance position because the integration was being used in the way the platform intended. Compliance and good architecture are often pointing in the same direction, and discovery is the place to find out where they align.

When the Platform Is the Problem, Not the Regulator

There is a useful distinction between regulatory compliance, which involves answering to a financial authority, and platform compliance, which involves satisfying Apple or Google's review policies. Both matter and both can block a product from reaching users, but they operate through different mechanisms and require different responses.

A regulator communicates requirements through published rules, formal correspondence, and authorisation processes. There is a defined route for obtaining clarity, and if your product meets the published requirements, authorisation follows. Apple and Google do not work this way. Their review processes are opaque, their criteria change without announcement, and there is no formal appeals mechanism when a rejection feels unjustified.

On the currency exchange project, we eventually concluded that Apple's repeated rejections were not primarily compliance-driven. The timing aligned with Apple Pay's launch, and the pattern of objections, each one resolved only to be replaced by a new one, suggested a strategic motivation. A fintech team that assumes App Store rejections are always genuinely compliance-based and responds by investing further in compliance work can lose significant budget chasing a moving target. Recognising when the platform is the problem rather than the product is a different kind of diagnosis, and it requires a different response.

Conclusion

The common thread across every regulatory challenge we have described here is timing. Compliance requirements found early are design constraints. The same requirements found late are reconstruction projects. The currency exchange product needed AML built into its architecture from the start, and because it was not, we spent time and budget rebuilding flows that should never have existed in their original form. The dating app project lost £15,000 and two months because discovery was skipped for one component. These are not unusual outcomes: they are what happens when regulated products treat compliance as something to address after the product takes shape.

The fintech category is genuinely more complex than most. The regulatory bodies are multiple, the platform policies are opaque, the payment provider constraints are architectural, and the consequences of getting it wrong accumulate. But the response to that complexity is to front-load the right conversations: which regulators apply, which flows carry AML obligations, which platform policies are most likely to create friction, and which payment provider constraints will shape what the product can actually do.

Discovery done properly in a fintech context is not longer than discovery in any other category. It covers different ground, and it produces a different kind of clarity. The products that reach launch in good shape are the ones whose teams had those conversations at the beginning rather than in the middle of a rebuild.

If you are building a fintech product and want to work through the compliance landscape before it becomes a constraint you are managing reactively, let's talk about your product.

Frequently Asked Questions