Fintech UX: designing for trust, compliance and speed

Good fintech UX lets a person answer three questions at every step: what am I agreeing to, where is my money right now, and what can I do if this goes wrong? Trust comes from those answers being visible when the decision is made. Speed comes from cutting steps that protect nothing, never the checks that protect the customer.

What makes good fintech UX?

Simpler onboarding, visible security cues and personalised insights all help, but they work on surfaces. The hard design problems in a financial product sit underneath: an offer that must be understood before it binds, a payment that stays in an in-between state for days, and an error that needs a route back.

Those three problems map onto the three questions a customer keeps asking, whether or not they say them aloud.

Two conditions run through all three. The answers have to work for people who use assistive technology or who are not financially fluent, and they have to hold up for the internal roles, such as reviewers, agents and administrators, who act on the same records the customer sees.

Speed means removing steps that protect nothing

Fast matters, and some financial onboarding is slower than it needs to be. But not every step is waste, and some cannot be removed at all. If your accounts are held at a US bank, federal rules require the bank to collect, at minimum, a name, date of birth, address and identification number before opening an account (31 CFR 1020.220). Since June 2025, banks may also obtain a customer's taxpayer identification number from a third-party source (Consumer Finance Monitor). For the rest, the design decision is not whether to ask but when and how: ask once the person understands why, say what the number is used for, and keep what they entered if verification stalls.

Other steps are protective by design. Since 9 October 2025, payment providers in the euro area must offer payers a free Verification of Payee check, which compares the recipient's name with the account number and returns "match", "close match", "no match" or "other" before the transfer is sent (European Central Bank). The payer can still go ahead after a warning, and if they do, they become liable for a payment that reaches the wrong recipient (PwC Legal). That puts real weight on one screen: the warning has to be read and understood at a moment when the person believes they are doing something routine.

The UK regulator has started naming this kind of step as good practice. The UK Financial Conduct Authority's March 2026 review of consumer understanding describes "positive friction" as short, purposeful pauses that help customers avoid harmful decisions.

A usable test for any step is to ask what it protects, and for whom. Checking a new payee protects the customer. Asking them to retype an address you have already verified protects no one. The same test catches the opposite failure: a flow that is fast to accept and slow to refuse. The US Federal Trade Commission's 2022 staff report on dark patterns lists burying key terms and junk fees, and making cancellation difficult among the common tactics. Declining an offer or cancelling a debit should never take more effort than accepting it.

Show where the money is

Money in a digital product can sit in between for days. On Stripe, for example, an ACH Direct Debit can take up to four business days to confirm success or failure, and in rare cases a failure arrives after the payment has already been marked as succeeded (Stripe ACH Direct Debit documentation). A screen that says "Paid" on day one is making a promise the payment rails have not made yet.

The same documentation notes that an ACH refund arrives as a new credit rather than a reversal, and recommends telling customers when a refund is issued so they recognise it and do not also file a dispute. That is a UX problem hiding in a payments document: the state exists, but only the business can see it.

Getting the displayed state wrong has a cost the customer pays. In 2022 the Consumer Financial Protection Bureau said that charging an overdraft fee on a debit card purchase that was authorised against a sufficient available balance, and settled later against a negative one, is likely unfair (Circular 2022-06). The Bureau withdrew that circular in May 2025, along with 66 other guidance documents (CFPB; Morgan Lewis), so read it as a design lesson rather than current US guidance. When the balance a product shows and the balance its fees are calculated on can disagree, the customer absorbs the surprise.

Design the way back

Every financial product has an exception path, and regulation can fix its clock. Under Regulation E, a US institution generally has 10 business days to investigate a reported error in an electronic transfer, or up to 45 days if it provisionally credits the account in the meantime (12 CFR 1005.11). In the UK, people who lose money to authorised push payment fraud over Faster Payments or CHAPS can claim reimbursement up to a set maximum, and should normally be reimbursed within five business days of the claim (Payment Systems Regulator).

Those are the clocks. The design question is whether the customer can see them: that a report was received, what is happening now, what they need to provide, and when they will hear back. A process can meet every deadline and still feel opaque if the only evidence of progress is silence.

Exceptions also pass between people. An application goes to manual review; a dispute goes to an operations team. If the reviewer cannot see what the customer was shown, and the customer cannot see that a person is now involved, both sides fill the gap with support contacts. Design the internal review screen and the customer's status view as one flow, with the same states and the same reasons.

Compliance is becoming a UX requirement

Treating compliance as legal text at the foot of a screen is getting harder to defend, because regulators increasingly describe outcomes that only interface work can deliver.

• Accessibility is now a condition of offering banking services to EU consumers. Since 28 June 2025, the European Accessibility Act has covered consumer banking services, including credit agreements, payment services and e-money. Identification methods, electronic signatures, security and payment services must be perceivable, operable, understandable and robust, and information about the service should not exceed B2 (upper intermediate) language complexity. The requirements follow the customer's location, not the firm's, and microenterprises are exempt from certain accessibility requirements (Hogan Lovells).
• Understanding has to be tested, not assumed. The FCA's March 2026 review, cited above, flagged weak evidence of testing and cosmetic changes that do not address root causes as areas for improvement. The good practice it describes looks a lot like product research: comprehension checks and A/B tests before and after changes, drop-off data and chat transcripts reviewed regularly, and key information placed first with detail layered beneath.
• Manipulative patterns are an enforcement topic. The FTC's 2022 report treats hidden fees and obstructed cancellation as design choices, not copywriting accidents.

The division of labour matters here. Your legal, risk and domain owners decide what the rule is. Design decides whether a person can understand and act on it. Where a rule cannot be shown in full, the person still needs to know the next step and the evidence it requires. Where a policy input is missing, the right move is to find its owner, not to invent the rule in the interface.

What our lending and payments work showed

At Tcules, two pieces of our work sit behind this guide. Neither is offered as proof of a conversion or trust metric; we have not published figures of that kind for either.

Mobile lending: OctiFi. OctiFi operated a mobile lending product in Singapore and was preparing for another Southeast Asian market. We started with a contained pilot and went on to continuing product-design work across onboarding, loan issuance, new features and adapting the application for the second market. The team used low-fidelity iteration to examine flows, then high-fidelity prototypes with realistic data so that product, engineering and marketing stakeholders could review the intended experience before investing in code. In that case, our work was modifying user flows to meet regulatory norms inside an agile, engineering-centred startup. (Read the OctiFi case.)

Our reading of it: a loan offer is hard to judge without realistic amounts, terms and fees in place, because sample text hides the comparison a borrower has to make. And the split of ownership is worth making explicit: the lender owns lending policy and regulatory decisions, and design works on how they are shown, at the pace of the engineering team.

Merchant payments: research before building. A client considering a payment product for kirana-store users, the small neighbourhood shops common in India, wanted evidence before committing to development. We combined stakeholder interviews, competitor analysis, and app-store and social research with twenty qualitative interviews with people matching the intended personas, then synthesised the findings into product and marketing priorities, concept material and a UX strategy. The work ended before implementation. (Read the merchant-payment research case.)

Our reading of it: public reviews and competitor apps show a category's recurring complaints and the words people use, but they do not replace speaking with the intended users. In payments, where habits and worries about money are specific to the people involved, that difference decides which problems deserve a place in the product.

Fintech UX trends worth planning for

These are changes already in force or in motion, rather than visual fashions.

The AI trend deserves particular care. A model can classify documents, summarise an account or recommend a next action, but the product should not make a probabilistic output look like a settled financial state. People need to know whether they are seeing a draft, a recommendation or an authorised action, and who can override it. We cover patterns for that in AI trust, control and human review.

A checklist before you ship a money flow

• [ ] Amount, term, fees and material conditions are visible together before the commit action.
• [ ] An estimate looks and reads differently from an approval.
• [ ] Every transaction state has a name, and the next expected change has a date.
• [ ] "Success" appears only when the payment rails confirm it; before that, the flow says "submitted" or "processing".
• [ ] The balance on screen is the balance fees are calculated on, or the difference is explained.
• [ ] Each friction step has a stated protection; steps without one are removed.
• [ ] Declining, cancelling or revoking takes no more effort than accepting.
• [ ] A failure says why, where the money is, what happens next and who owns it, and keeps what the person entered.
• [ ] A dispute or fraud report shows receipt, current stage, evidence needed and the expected decision date.
• [ ] Reviewers see what the customer saw, and the customer can see when a person is involved.
• [ ] Sign-in, authentication and payment steps have been tested with assistive technology users.
• [ ] Key screens have been tested for understanding with real customers, before and after the change.
• [ ] Any AI output is labelled as a draft, recommendation or authorised action, with a named role that can override it.

Where this work sits

If your product has a financial moment people find hard to understand, such as an offer, a payment state or an exception, that is where our fintech and insurtech product design work starts. We research the workflow, model roles and states, and prototype commitment and recovery, while your risk, legal and domain owners keep regulated policy, underwriting and final approval.

Where the problem is an existing product whose flows have drifted over years of releases, the underlying condition has a name: UX debt.