Fintech UX: when compliance is a design input, not a checklist

The product manager pulled up the KYC flow on his laptop and said something I've heard variations of from every fintech founder I've worked with: "Legal made us add these screens. They're awful. We know. There's nothing we can do."

What I saw on the screen was four pages of dense consent text, three of which the user had to scroll to the bottom of before the "accept" button became enabled. A fifth page with a video selfie capture that wouldn't proceed unless the user smiled. A sixth page that re-asked for tax residency the user had already entered on page two. Each page was a screen designed to satisfy a compliance requirement someone else had written, glued onto a product someone else had designed. The result was the canonical fintech onboarding: legally bulletproof, operationally functional, and from the user's perspective, indistinguishable from a hostage negotiation.

"Legal made us add these screens" is the sentence that gives away the model the team is operating under. Compliance is a checklist. Design is a separate thing. The checklist gets satisfied at the end, the design happens in the middle, and the two collide at the boundary. The collision is what produces the consent-modal hell most fintech onboarding flows put users through.

The alternative model is harder to adopt and produces materially better products. Compliance as a design input, not a checklist. The same regulatory requirements that produce the bulletproof KYC flow can also produce a clean one — but only if the design conversation starts with the constraint, rather than ending with it.

This post is about what changes when you flip the model. Specifically: seven moves that fintech UX teams routinely under-invest in, and how each of them changes when compliance is upstream of the design instead of downstream.

I haven't shipped a regulated bank under my own name. The closest thing in my work is the Enrichplay crypto product, which sits in the regulatory grey zone between fintech and crypto and gave me the chance to design transaction confirmations and consent flows that needed to clear the same kind of scrutiny as a regulated app. The principles below come from that work plus four years of fintech consulting — onboarding flows, transaction screens, dispute submission paths, the long tail of compliance-adjacent design that most products treat as an afterthought.

The two mental models, side by side

The shift in posture is the move. Once you decide that compliance is a design input rather than a checklist, the rest follows. Below I walk through what follows — the seven design decisions that get materially better when the posture changes.

1. KYC: the consent-pattern problem

The constraint: Identity verification (Know-Your-Customer) typically requires a government ID, a selfie or liveness check, address verification, and an explicit consent to the platform's terms — all of which the regulator will eventually audit.

What the checklist model produces: Four to six sequential screens, each containing one requirement. ID upload, selfie capture, address form, terms acceptance, source-of-funds (for higher tiers), tax residency. Each screen is a hard wall the user has to clear. The flow has no narrative — it's a sequence of forms that happen to be next to each other.

What the input model produces: The same data captured, in three screens, with a progress bar that names what's been done and what's left.

• Screen 1: Identity — ID upload + selfie liveness in one flow. The user sees both upfront so they know what's coming; the liveness step inherits the trust just established by the ID upload.
• Screen 2: Residence + tax — address, country of residence, and tax residency on one page. These are the same questions the regulator wants and the user resents being asked separately.
• Screen 3: Review + consent — a single-screen summary of what's been captured, the consent language inline (no separate "terms" page), and a single proceed CTA.

The flow doesn't have fewer requirements. It has fewer screens. The difference matters because each screen is a chance for the user to drop off. The checklist model's six-screen flow drops 8-15% of users at each step — by the end, you've lost 30-40% of qualified onboarding starts. The input model's three-screen flow loses fewer because it asks for clustered information in the order the user can answer it.

The consent language is the part teams find hardest to fold in. Legal will hand you 800 words of paragraphs. The temptation is to scroll-lock the user behind it. The better pattern: take the same 800 words, break them into the four or five claims they actually make, and render each claim as a checkbox the user actively acknowledges. "I understand my funds may be held for up to 5 business days for compliance review." [✓] "I understand verification may be revoked if information turns out to be incorrect." [✓] etc. The legal claim is the same. The user is now an active participant rather than a passive scroll.

Pattern: consent that asks the user to acknowledge specific claims converts roughly 20-30% better than consent that asks them to accept all terms — without weakening the legal posture. The legal team gets stronger evidence of informed consent. The product gets a higher conversion rate. Both teams should want this.

2. Transaction screens: showing the consequence

The constraint: Every financial transaction the user initiates has a consequence the user needs to understand before they commit. Regulators (and good designers) both insist on this. The principle is Nielsen's fifth heuristic — prevent errors at the source — which I wrote about in detail in the named-laws audit post.

What the checklist model produces: A confirmation page that lists "From account: X, To account: Y, Amount: $Z" with a "confirm" button. Legally bulletproof. Operationally fine. Cognitively flat.

What the input model produces: A confirmation page that names the consequence in the user's language, not the platform's.

• From: "Your Chase checking account ending in 4811"
• To: "Sam Khan's Cash App, which they confirmed yesterday"
• Consequence: "This transfer is final once you confirm. Sam will see the $200 in their account within minutes; we can't recall it if you change your mind."

The consequence sentence is the move. It says what's about to happen in plain language, and it explicitly names the irreversibility (or reversibility) of the action. The user doesn't have to infer it.

Crypto products live or die on this. The Enrichplay confirmation screens include a "you cannot recover this transaction once signed" line above the sign button. That line isn't there because the regulator demands it. It's there because the user needs to feel the consequence before they tap. Once they feel it, the regulator's bulletproofness comes for free.

The same pattern applies to fiat fintech. The "transfer $X to Y" confirmation page is the user's last chance to back out before money moves. Make the consequence legible. Make the back-out path at least as visible as the proceed path. Make the proceed path require an intentional gesture (a slider, a hold-to-confirm, a passcode re-entry) for transactions above a threshold.

The friction protects the user. The friction also protects the platform from the disputes that come when a user later claims they didn't understand what they were doing. Both are compliance wins. Neither feels like one to the user, because the friction reads as care rather than as bureaucracy.

3. Disclosures: when they go inline vs. modal vs. separate page

The constraint: Most regulated products have disclosures that must be shown to the user at specific points in the flow. Investment products need risk disclosures. Lending products need APR disclosures. Crypto products need volatility and custodial disclosures.

What the checklist model produces: A modal that pops up at the disclosure point, full of legal text, with a "got it" button. The user dismisses it without reading. Compliance is satisfied; comprehension is zero.

What the input model produces: A decision matrix about where the disclosure goes based on what kind of information it carries.

The matrix isn't arbitrary. It's a function of two variables: how much information density the disclosure carries, and how often the same user will need to see it.

A user who deposits crypto every week doesn't need a modal explaining custodial risk every time. They need it on their first deposit (modal-with-acknowledgment) and a permanent banner link in their settings. A user who's quoting an APR on a loan needs that APR in the flow, not in a modal — because the APR is the input to the decision they're making, and any disclosure that's not in the decision surface is in the wrong place.

The teams that get this right design disclosures as part of the flow, not as gates on the flow. The disclosure becomes part of the user's information set rather than an obstacle to it.

4. Audit trails users can see

The constraint: Regulated products keep detailed audit trails of every user action — transaction history, consent timestamps, device fingerprints, settings changes. Most of this lives in internal admin tools, visible only to compliance and support.

What the checklist model misses: The user-facing version of the audit trail is treated as a "history page" — a list of past transactions with timestamps. It satisfies the regulator. It doesn't help the user.

What the input model produces: A user-facing audit trail that mirrors the internal one, with the user's data exposed as transparency rather than as compliance theater.

• Every transaction shows not just amount and date, but who saw it, when it was processed, what status changes it went through, and what compliance checks ran on it.
• Every consent the user gave is visible in their settings, with the date and the language they agreed to at the time. The user can re-read the terms they accepted in 2024 if those terms have since changed.
• Every login from a new device shows up as an alert the user can review and revoke.
• Every change to a setting (especially security-sensitive ones — two-factor, withdrawal limits, address book) is logged in a user-visible way.

The reason this matters: trust is a UX property, not a marketing one. The user who can see their own audit trail trusts the platform more than the user who can't, even if the underlying compliance posture is identical. The transparency is a felt-trust signal, and felt trust is the difference between a fintech product the user uses and one the user tolerates.

The teams worried about "showing too much" usually find that showing more is the better trade. The user who can see the audit trail is the user who reports anomalies fast, who doesn't escalate to support for things they can verify themselves, and who tells their network that the platform "doesn't hide anything." All three are wins. None of them costs anything beyond surfacing data that already exists.

5. Accessibility and compliance: where WCAG and financial regulation align

The constraint: Financial regulation in most jurisdictions explicitly requires the product to be accessible to users with disabilities. The Americans with Disabilities Act (US), the European Accessibility Act (EU, effective 2025), and similar frameworks in the UK, Canada, and Australia all set accessibility floors for financial services.

What the checklist model misses: Accessibility is usually treated as a separate compliance domain — handled by a one-off audit at launch, then forgotten. Most fintech products ship at WCAG AA on the marketing site and well below it on the in-product flows where it matters most.

What the input model produces: Accessibility folded into every design decision, with the financial-regulation overlap doing useful work.

The overlap is more useful than most teams realize. Several WCAG criteria are directly implicated by financial-regulation requirements:

• WCAG 2.4.6 (Headings and labels) is the same requirement as "clear and prominent disclosure of terms." A clear visual hierarchy is also a legible disclosure.
• WCAG 3.3.4 (Error prevention — legal, financial, data) is the same constraint as "explicit confirmation before destructive financial actions." A reversible, confirmable action is both accessible and compliant.
• WCAG 1.4.3 (Contrast minimum) is the same constraint as "disclosures must be legible." Pale grey text on white isn't just inaccessible — it's plausibly a regulator's "obscured disclosure" finding.
• WCAG 2.4.7 (Focus visible) is the same constraint as "user must be able to tell what action they're about to commit to." Visible focus state is a trust signal regardless of disability.

A fintech product designed to WCAG AA is also a fintech product with a stronger compliance posture. The teams that recognize this run accessibility and compliance reviews as one pass instead of two. The cost is roughly the same. The quality of the outcome is higher because the two constraints reinforce each other.

For deeper accessibility coverage — including screen reader testing, keyboard-only flows, and motion-sensitivity considerations — the principles transfer cleanly across to any compliance-sensitive product, including crypto and lending platforms.

6. Designing for the regulator as a secondary user

The constraint: Most fintech products have at least two user types — the primary user (the customer) and the regulator (who occasionally audits the product, reads the disclosures, and decides whether the product is operating within scope). Design teams design for the first. They rarely design for the second.

What the input model proposes: Treat the regulator as a secondary user — not as a customer, but as a real audience whose comprehension matters.

This shows up in practice as a handful of small decisions:

• Disclosure copy is written to be legible to a non-customer reader. A regulator who picks up the disclosure six months from now needs to understand what was disclosed without needing to use the product. The copy passes that test.
• The consent record is auditable from the product, not just from the database. A regulator's request for "show me how this user consented to the risk disclosure" returns a screen the user actually saw, not a database row that requires interpretation.
• The compliance state of any account is visible inside the product. A regulator (or a customer-support agent who's about to talk to a regulator) can see what tier the account is on, what disclosures have been delivered, what consent records exist, and what review states are active.
• The audit trail is exportable. Not as a CSV that has to be sense-made — as a human-readable PDF or web view that a non-engineer regulator can read in the order it was generated.

The regulator-as-secondary-user framing is what separates the fintech products that go through audit cleanly from the ones that survive audits by attaching emails to engineering tickets. The first set has the regulator's needs designed into the product. The second set has them retro-fitted into screenshots.

This is the design move with the biggest upside-to-cost ratio in fintech UX. The work to surface the audit trail in a regulator-legible way is small. The work to not surface it, and then to manually compile evidence every time the regulator asks, is large and recurring.

7. The flow-level move: name the compliance constraint upfront

The seventh move is the simplest and the most often skipped: at the start of the design conversation, name the compliance constraints out loud.

"This is a KYC flow. The constraints are: government ID, liveness selfie, address verification, tax residency, source of funds for tier-2 users, and explicit consent to terms. We have to capture all six. We don't have to capture them in six separate screens. How do we cluster them?"

That sentence is the difference between a flow designed for compliance and a flow designed with compliance. The second version produces a measurably better product because the design conversation starts with a complete picture of the constraints, rather than discovering them one screen at a time as legal pushes back on the first draft.

The teams that operate this way invest a couple of days at the start of the engagement in a compliance-mapping session. The legal/compliance lead walks the designer through every requirement that touches the flow. The designer asks "what's the source of this requirement" for each one — sometimes a regulation, sometimes an internal policy, sometimes a residual habit from a previous product. Some requirements come off the map because they were never actually required; others stay on the map but get clustered differently. The clustering work is the actual design work, and it can only happen if you have the full map upfront.

The teams that don't operate this way ship a v1 designed without the constraints, get blocked by legal in pre-launch review, redesign in a panic, and ship a v1.5 with the consent-modal hell that the original poorly-scoped flow forced on them. v2 might be designed better; v2 usually comes after the design team has already burned out on the project.

What this framing protects you from, and what it doesn't

Treating compliance as a design input doesn't change what the regulator requires. It changes how those requirements show up in your product. The user-visible result is a flow that feels respectful rather than punitive. The internal result is a design process that doesn't collapse into emergency-redesign cycles every time legal weighs in.

What this framing doesn't do: it doesn't replace legal review, it doesn't substitute for an actual compliance program, and it doesn't change the regulatory landscape your product operates in. Treat the seven moves above as design discipline, not as a legal strategy. The compliance team owns the legal posture. The design team owns whether the legal posture shows up as a clean product or a cluttered one.

The choice between compliance as checklist and compliance as design input is the choice between two versions of the same legally-compliant product. One of them is the version users tell their friends about. The other is the version they tolerate because their employer told them to use it. Same constraints, different posture, different product.

If you're scoping this work

If you're a fintech founder running into compliance-as-checklist symptoms — drop-off at consent screens, disputes the user claims they didn't understand the action, audit prep that takes weeks of manual evidence collection — the fintech UX designer page covers what a typical engagement looks like. The crypto-wallet UX page is the right shape if your product sits in custodial/non-custodial wallet territory specifically. Both pages link through to scoping conversation.

A couple of adjacent pieces if the framing here resonated:

• How I anchored a UX audit to four named laws — Nielsen's fifth heuristic in particular maps directly onto the transaction-confirmation patterns above.
• Designing a crypto product that holds together across mobile and web — the systems work underneath Enrichplay, which is where the compliance-as-input posture got tested.
• The Enrichplay case study — the closest thing in my shipped work to a regulated-product flow, with the transaction confirmation patterns visible end-to-end.

Compliance and design are not opposing forces. They look like opposing forces only when one of them is upstream of the other. Once they're in the same conversation, the same constraints produce a materially better product.