What do regulators check first when reviewing your app?

Regulatory review is a sequence, and that sequence has a logic to it. Regulators and platform reviewers tend to start with the most serious potential harms, work outward to lesser ones, and only then consider things like user experience and design. Understanding that order changes how you build a product, and it changes what you fix first when a rejection arrives.

Build compliance in the right sequence and you find each layer before a regulator finds it for you.

We learned this in an uncomfortable way on a peer-to-peer currency exchange product, where users could trade leftover foreign currency with other travellers at interbank rates, bypassing commission. The core transfer mechanism worked well. We had built something genuinely useful. But we had not factored in anti-money laundering requirements, and Apple flagged it as a potential vehicle for financial crime. The rejections that followed ate budget, forced a near-complete compliance rebuild, and ultimately contributed to the product never reaching market. The lesson was not that compliance matters. That was already known. The lesson was that the sequence in which you encounter compliance obligations maps almost exactly to the sequence regulators use when they review your app.

This article walks through that sequence, explains what sits at each layer and why, and points to the places where a rejection may have nothing to do with compliance at all.

The sequence regulators actually follow

Platform reviewers and statutory regulators do not assess apps randomly. They work through a hierarchy of concern, and that hierarchy is roughly the same whether the review is happening at Apple, Google, the FCA, or a national data protection authority. Financial crime sits at the top because the potential harms are largest and the legal exposure for inaction is most severe. Identity and authentication come next because they are the precondition for everything else. Data handling follows, then content safety, and finally design and experience concerns.

This hierarchy exists for a reason. A product that launders money is a more urgent problem than one that mishandles push notification consent. A product that cannot identify its users cannot reliably enforce any of the layers below. Reviewers therefore check the highest-stakes layer first and only proceed if it passes. If it fails, they stop there and send it back.

The practical consequence is that products built without a compliance sequence tend to get stuck at the first layer they have not considered. Fix that, and the next layer surfaces. That cycling through objections is expensive and demoralising, and it is entirely avoidable if the sequence is understood before build begins rather than discovered through repeated rejection.

Identity and authentication checks

The first substantive question any reviewer asks is whether your product can identify its users. This is about whether, if something goes wrong, there is an auditable trail connecting an action to a person. Regulators need that trail. Platform reviewers need confidence that you have the architecture to provide it.

On an anonymous messaging app we worked on, we put authentication right at the front of the user journey, which ran against our usual instinct to defer login until the user has experienced enough of the product to understand its value. The nature of the product forced the exception. Messages needed to be anonymous to other users inside the app, but on the back end, every message had to be traceable to a specific account. If abuse or harassment occurred, we needed a legal mechanism to act. Without front-end authentication, that mechanism did not exist.

That project clarified something we now apply more broadly. The question is not whether to authenticate early or late. The question is what legal and safety obligations your product carries, and whether those obligations require a user identity to be established before the product becomes usable. For most lifestyle apps, the answer is no. For anything involving financial transactions, messaging, or user-generated content with safeguarding implications, the answer is often yes.

Map your legal obligations before deciding where authentication sits in your user journey. If your product can be used to harm others before a user is identified, authentication should come first.

Financial crime controls: AML and KYC

Anti-money laundering controls and Know Your Customer checks are the layer most products in lifestyle categories do not think they need, right up until they do. The currency exchange product we built sits exactly in that gap. It was a consumer travel product, not a financial services platform in any traditional sense. But the mechanism, users transferring money to other users with minimal friction, was indistinguishable from a money laundering vehicle if the compliance layer was absent.

Apple's reviewers flagged it as such. We responded with more stringent KYC checks, enhanced transfer security, and hard limits on the number of transfers permitted between any two parties. We eventually capped individual transactions at €150, which we believed should have removed any plausible concern about criminal use at scale.

Capping transactions at €150 per transfer should have resolved Apple's concern, but the app was rejected again.

Apple rejected the app again. There is more to say about that in a later chapter. The point here is that any product involving value transfer between users, even small-scale consumer transfers, will encounter AML and KYC scrutiny. Building those controls after your first rejection is far more expensive than building them in from the start. The architecture changes, the data model changes, and often the user flow changes too.

What AML controls actually involve

At a practical level, AML controls for consumer apps mean three things. First, a mechanism to verify user identity against a recognised standard, which at minimum means email and phone verification and at higher risk levels means document verification. Second, transaction monitoring that flags unusual patterns, either by volume, frequency, or the relationship between sending and receiving parties. Third, hard limits that make it structurally difficult to use the product for laundering at scale, even if a bad actor attempts it.

What KYC involves at the product level

KYC is the upfront component. It sits in onboarding and asks the user to establish who they are before they access certain product features. The friction this creates is real, and there is a genuine design challenge in making KYC feel like a natural part of the product rather than a compliance checkpoint bolted on at the end. The way through it is to frame it honestly: the product works better, and the user is better protected, when their identity is confirmed. That framing reduces drop-off without hiding the purpose.

Data handling and privacy compliance

Once financial crime controls and identity checks pass, the next layer is data. This covers how personal data is collected, stored, transmitted, and deleted, and whether users are given adequate notice and control over those processes. For apps operating in the UK or EU, this means GDPR compliance. For apps with users under 18, the Children's Code adds a further set of obligations around data minimisation and default privacy settings.

Regulators reviewing data handling look at a few things in particular. Consent architecture matters: is the user genuinely choosing to share data, or is the interface designed to make refusal harder than acceptance? Data minimisation matters: are you collecting only what the product genuinely needs, or are you collecting broadly and deciding later? Retention policies matter: what happens to a user's data after they delete their account?

The design layer connects directly to the regulatory layer here. Consent interfaces that use pre-ticked boxes, obscure rejection paths, or mismatched visual prominence for accept and decline options will fail a data protection review. That is a design decision made during build, and it needs to be made with the regulatory standard in mind from the start.

Review your consent interfaces against the ICO's published guidance on valid consent. If the decline path takes more steps than the accept path, the interface will not pass scrutiny.

Content moderation and safety obligations

For apps where users can produce or share content, including reviews, messages, comments, or any kind of social feed, content moderation becomes a distinct compliance obligation. The Online Safety Act in the UK creates statutory duties for platforms to assess the risk of illegal content and implement proportionate systems to address it. The detail varies by platform size and category, but the principle applies broadly.

This is not simply about removing harmful content after it appears. Regulators expect a risk assessment, a policy, a reporting mechanism, and a process for handling reports within a defined timeframe. A wellness brand launching a community feature, a food and drink app with a recipe submission tool, or a fitness platform with a social training feed all carry some level of content moderation obligation once user-generated content is in scope.

The anonymous messaging product is where this tension is most exposed. Authentication was the precondition for content safety: without it, there was no mechanism to act on a harassment report, suspend an account, or provide a court with evidence if required. Building content moderation backwards, starting with the moderation policy and then discovering the authentication architecture was not in place to support it, is a common and costly sequencing error.

Minimum viable moderation infrastructure

At minimum, a content-carrying app needs a reporting function accessible from the content itself, a defined internal process for reviewing reports, a way to suspend or remove accounts, and a record of moderation decisions. These are not ambitious requirements, but they need to be built into the product from the start rather than added after a platform review flags their absence.

Platform-level rules versus statutory rules

There is an important distinction between rules set by law and rules set by platform operators, and conflating them leads to badly targeted compliance work. Statutory rules, GDPR, AML regulations, the Online Safety Act, are set by legislatures and enforced by regulators with legal powers. Platform rules are set by Apple, Google, and others under their own terms of service, and enforced by the platform's review team through rejection or removal.

Both matter, but they are not the same kind of constraint. Statutory rules are non-negotiable and apply regardless of where you distribute your product. Platform rules apply specifically to apps distributed through that platform, and they can be changed without notice, applied inconsistently, and in some cases used strategically rather than in good faith.

Understanding this distinction matters for how you respond to a rejection. A statutory compliance gap needs to be fixed because the law requires it. A platform rejection requires first determining whether the objection is genuine, consistent, and applied in good faith, and then deciding how to respond. Those are different problems and they deserve different responses.

When rejection is not really about compliance

On the currency exchange project, Apple's repeated rejections followed a pattern that became hard to explain purely through compliance concerns. Each time we addressed the stated objection and resubmitted, a new objection appeared. We capped transactions at €150. We added KYC checks. We added transfer limits. Each time, Apple found a new reason to reject. The process has no effective mechanism for a developer to challenge this behaviour.

It later became clear that Apple Pay and other payment services launched around the same period. The pattern of objections, escalating and shifting despite genuine compliance work, suggested the rejections were motivated by competitive concern rather than regulatory principle. A product that let users bypass foreign exchange fees at scale was a direct competitor to services Apple was building or had invested in.

The client spent significant money on legal counsel and compliance work across this period. Eventually the budget ran out and the product was abandoned. It never reached market despite being functionally sound and, by any reasonable standard, compliant with the requirements that had been stated to us.

If a platform raises a new objection each time you satisfy the previous one, document every exchange in detail. The pattern of objections is evidence, and it may become relevant if you need to escalate or change distribution strategy.

This is an argument for understanding that a rejection letter and a compliance failure are distinct, and that the appropriate response depends on accurately diagnosing which one you are dealing with.

Building to the sequence from day one, not retrofitting it

The most expensive compliance work is the kind done after the product is built. Retrofitting KYC into an onboarding flow that was designed without it means rebuilding the data model, the user journey, and often the back-end architecture at the same time. Retrofitting content moderation infrastructure means adding a reporting layer to a product that was not designed to carry one. Each of those changes compounds the others.

On the currency exchange product, the compliance rebuild after Apple's first rejection was not a matter of adding a checkbox. It required new identity verification integrations, a transaction monitoring layer, changes to how user relationships were stored and tracked, and a revised flow for users who needed to pass stricter KYC before accessing the transfer feature. All of that added time and cost to a product that had already been built once.

The sequence we described in this article, financial crime, identity, data, content safety, platform rules, statutory rules, is also the order in which compliance architecture should be designed. Start with the most serious obligations, design the product around them, and each subsequent layer becomes easier to add because the infrastructure is already in place. A product designed with AML controls from the start has the user identity and transaction data structures it needs for KYC. A product with robust identity architecture has what it needs for content moderation. The layers connect.

A working pre-launch compliance check

1. Identify whether your product involves value transfer between users, and if so, what AML and KYC obligations apply.
2. Determine whether legal or safety obligations require user identity to be established before the product is usable.
3. Review every consent interaction against the standard for valid, freely-given consent.
4. Assess whether user-generated content is in scope, and if so, what moderation infrastructure is required.
5. Map your target distribution platforms and review their specific policies for your product category.

Conclusion

Regulatory review follows a sequence, and that sequence is not arbitrary. It reflects a hierarchy of harm, with the most serious potential harms checked first and lesser concerns addressed only once the serious ones pass. Financial crime controls sit at the top. Identity architecture underpins everything below it. Data handling, content safety, and platform-specific rules follow in that order.

The currency exchange product taught us that discovering this sequence through rejection is far more expensive than understanding it before build begins. The anonymous messaging app showed that the same architectural decision, putting authentication upfront, can be both a legal obligation and a design principle when the product's nature demands it. These were not edge cases in unusual industries. They were consumer lifestyle products built by careful teams who had not yet mapped their compliance obligations to the sequence reviewers actually follow.

The gap is almost always a sequencing problem rather than an ignorance problem. Teams know compliance matters. What is less clear, until it is demonstrated through a rejection, is that the order in which you build compliance layers determines how much of your architecture survives contact with a regulator. Build the layers in the right order and each one supports the next. Build them out of order and you rebuild the earlier ones to support the later ones, which is the slowest and most expensive way to arrive at the same destination.

If you are building a product that carries any of the obligations described in this article, and want to work through the sequence before a reviewer does it for you, let's talk about your compliance architecture.

Frequently Asked Questions