Fintech UX: how do you design apps that work with money?

In short

When designing a fintech app, one question drives every screen: can the user lose money on this screen? If the answer is yes, that screen needs more care than the others.

Adding the wrong product to the cart in an online store is a small problem. Sending money to the wrong account, on the other hand, can turn into days of hassle. The job of fintech UX is to carry that difference into the design.

When I review a product that works with money, I check six areas one by one. The sections below follow that order.

What builds trust

Users trust a fintech product when they know in advance what each tap will do. On a screen that handles money, anything unexpected causes unease.

The first of Jakob Nielsen's 10 usability heuristics is the ground rule here: the system should keep users informed about what is going on, with appropriate feedback within reasonable time. On money screens that means:

• Fees, charges and the exchange rate are on screen before the button is pressed. A fee that first appears on the receipt is enough for the user never to trust that screen again.
• The transaction status is named clearly: sent, pending or declined. “Your request has been received” doesn't say which of the three it is.
• The balance updates right after the transaction. If it can't, the reason is on screen.
• The language stays plain. “$1,500 sent to Anna M.” is shorter than “Your transfer order has been accepted for execution” and says more.

Something else destroys trust: tricks in the interface that steer the user. A pre-ticked insurance box or a hidden path to cancel brings revenue in the short term and complaints in the long term. I describe these patterns one by one in the guide to dark patterns.

KYC and authentication

KYC (know your customer) is the process in which a financial institution verifies its customers' identity. For the user, it means holding an ID and their face up to the camera when opening an account. Some products add a video call.

At the KYC step the user usually hasn't used the product yet, but is giving away the most data right now. That's why I consider this step the most sensitive point of onboarding. In my work I look at the following:

• Before the start, it says what is needed: an ID and good light. That way nobody searches for their ID halfway through.
• Every document is explained in one sentence.
• The camera screen gives live feedback: “Hold the ID closer to the frame”, “Not enough light”. Reporting only “Verification failed” makes the user repeat the same mistake.
• Progress is saved. If the app closes, the user doesn't start over.
• There is another path for someone who can't use the camera, and it isn't hidden.

I describe the flow step by step in the guide to the KYC flow.

Sign-in and approval

In the EU, the second Payment Services Directive (PSD2, Directive (EU) 2015/2366) sets when strong customer authentication is needed. Under Article 97(1), the payment service provider has to apply it when the payer accesses their payment account online, initiates an electronic payment, or carries out any action through a remote channel that may imply a risk of payment fraud or other abuse.

Article 4(30) defines what “strong” means: two or more independent elements from the categories knowledge, possession and inherence. For electronic remote payments, Article 97(2) also requires elements that dynamically link the transaction to a specific amount and a specific payee. This is not legal advice; the current text and your compliance team are what count, and other markets have their own rules.

For design, this second point is a gift. If approval is tied to amount and payee anyway, show both prominently on the approval screen or in the push notification. The user then doesn't approve “a payment”, but “$1,500 to Anna M.”.

The real design question is how much these security steps wear the user out. Criterion 3.3.8 of WCAG 2.2 (AA) is clear here: according to the W3C's explanation, a verification code sent by SMS must at least be possible to paste. A service that forces the user to type the code by hand doesn't meet the criterion.

The same explanation names filling in with a password manager and copy and paste as ways to meet the criterion. Blocking paste in the password field looks like security. In my opinion it only pushes users towards shorter, easy-to-remember passwords.

Session length belongs here too. Someone who goes to find the invoice number and comes back loses everything they entered if the session has expired in the meantime.

Criterion 2.2.1 of WCAG 2.2 (A) describes one way out: the user is warned before time runs out. They get at least 20 seconds to extend the time with a simple action.

Confirm and undo when money moves

On the transfer screen, two tools catch mistakes: confirmation and undo. Confirmation tries to catch the mistake before it happens. Undo gives the user a way out after the mistake has happened.

Nielsen's third heuristic asks for that way out: users often do things by mistake and should be able to leave an unwanted action without a long process. The fifth heuristic is about error prevention: removing error-prone conditions or asking for confirmation before the action.

Criterion 3.3.4 of WCAG 2.2 (AA) makes this explicit for financial transactions. On a page that carries out a financial transaction on the user's behalf, at least one of these has to be true:

• The submission can be reversed.
• The input is checked for errors, and the user gets the chance to correct it.
• Before the final submission there is a way to review, confirm and correct the information.

How a confirmation screen works

Nielsen writes in his article on confirmation dialogs that asking for every action teaches users to click on without reading. That's why a generic “Are you sure?” dialog protects nobody.

His recommendations fit fintech exactly. The confirmation screen restates the user's intent with recognisable details. Instead of “Yes / No”, the buttons carry labels that say what happens.

The article also has a bank example. A confirmation might be asked only for payments at least twice as large as the user's usual payments. Nielsen adds that this threshold is only an example, and the real value has to come from user research.

In a transfer the user has to check two things: who and how much. Both belong in the most visible place on the screen.

• Who: nobody reads an account number digit by digit, but a masked account holder name is recognised at a glance. In the UK, a name check called Confirmation of Payee has been running since 2020. Pay.UK describes it as an account name-checking service designed to help reduce misdirected payments.
• How much: the amount is large and repeated on the button. If it's outside the usual range, it gets its own warning.

A window to undo

Nielsen writes in the same article that confirmation dialogs slow the workflow down. He recommends putting a lot of effort into an undo feature.

If the money reaches the recipient's account instantly, there's no room for undo. Undo is only possible if the transfer is held back briefly.

That waiting time is a product decision and doesn't suit every transaction. I find that a few seconds hardly bother anyone when sending to a saved contact. But they're enough for a typo.

1. RecipientEnter account details or pick a saved contact.
2. Name checkThe account holder’s masked name is shown.
3. Repeat the amountThe amount is large; anything unusual gets a warning.
4. Send and waitA short window to undo begins.
5. ReceiptNotification and history show the same information.

Figure: five places where the user can catch a mistake in a transfer. The order is my suggestion.

Transfer confirmation screen

Two confirmation screens for the same transfer, one below the other. The user meant to enter $1,500 and typed one zero too many.

Send moneyConfirm

Recipient accountAccount 000123456789 · Routing 123456780

MemoRent

Amount: $15,000.00. Fees may apply.

Confirm

Flawed version

• The screen shows only the account and routing numbers. Nobody reads 21 digits one by one, so the user can’t see who the money goes to.
• The amount is small and grey inside a sentence. An extra zero goes unnoticed.
• The button says “Confirm”. It doesn’t say what you confirm.
• After the tap the money leaves at once. There is no way back.

Send moneyConfirm

Account holder name AN** MIL**** Account 000123456789 · Routing 123456780 The name comes from the recipient bank’s records. If you don’t know this person, don’t send.

Amount $15,000.00 Fifteen thousand dollars Fee: $0.00

You have never sent this person more than $1,500. Check the amount again.

Send $15,000 Fix the amount

Good version

• The recipient’s name is masked but recognisable. The user sees at a glance who they are sending to.
• The amount is large in figures and again in words below. An unusual amount gets its own warning.
• The button says what happens: amount and action. Next to it there is a way to fix the amount.
• The transfer is held back briefly. During that time it can be cancelled with “Undo”.

The screens, bank and names are made up. Scenario: the user meant to enter $1,500 and typed one zero too many. Switch between the flawed and the good version and tap the buttons. In the good version the transfer is held for 10 seconds and can be cancelled.

Both screens show the account details and the amount. The difference is where and how big that information is. On the flawed screen the amount is there, but doesn't catch the eye.

Error prevention

Before you write an error message, try to prevent the error. Page Laubheimer describes ways to avoid unconscious slips, mistakes made through inattention, in his NN/g article. On money screens it looks like this:

• Constraints. When the valid values are known, limit the input. A US routing number has 9 digits, so the field takes no more. If the amount is higher than the balance, the user is warned before pressing the button.
• Flexible format. The user can paste account details with or without spaces. The system cleans this up in the background and shows no error. A phone number also formats itself while typing.
• Good defaults. Recent recipients are at the top of the list. Nobody types the same account details every month.
• Suggestions. Saved contacts are suggested while typing. The user recognises instead of remembering.

Then there's the double transfer problem: on a slow connection, the user presses “Send” a second time. After the first tap the button has to switch to “Sending” at once and accept no second tap. The same transaction must never go out twice.

For the rest of the form, the rules from form design apply here too. The label sits above the field, the error right below it, saying what to do.

Notifications

In fintech, the transaction notification is part of the transaction itself. When money leaves the account, the user should find out without opening the app. Someone who spots a transaction they didn't make in the first notification can freeze their card right away.

My checklist for a good transaction notification:

• Amount and currency.
• Counterparty: the recognisable name of the recipient or merchant.
• Status: sent, pending or declined.
• What to do if the user doesn't recognise the transaction, and how to do it in one tap.

Putting transaction notifications in the same channel as marketing notifications is a mistake. To get rid of the marketing, the user may switch off all notifications and then notice a charge too late. In the settings, both kinds have to be switchable separately.

Notification and app have to say the same thing. If the notification says “sent” and the history says “pending”, the user doesn't know what to believe.

Accessibility

People with low vision or who use a screen reader pay bills too. A financial app that isn't accessible forces them to ask for help. With money, getting help sometimes means sharing a password with someone else.

I summarised the WCAG 2.2 criteria from above in a table.

Criterion	Level	What it means in fintech
3.3.4 Error Prevention (Legal, Financial, Data)	AA	The transfer can be undone, is checked, or is reviewed before sending.
3.3.8 Accessible Authentication	AA	The SMS code can be pasted; the password manager works.
2.2.1 Timing Adjustable	A	A warning comes before the session expires, and time can be extended with a simple action.
4.1.3 Status Messages	AA	The “Sent” message reaches the screen reader without moving focus.

These four criteria are only a start. Basic criteria such as contrast, tap area and keyboard are in the WCAG guide.

For the countdown in the demo I had 4.1.3 in mind. The time is on screen as text and is announced to the screen reader once at the start. If every second were announced, the user would hear nothing else.

My note

A problem I often see in fintech products: the user carries the burden of security. Codes that can't be pasted, or messages like “Transaction declined” with no reason, are examples. The team defends them as security; the user experiences them as obstacles.

My rule: every security step tells the user why it's there. Nobody gets annoyed by a screen that says “This amount is higher than usual, so we're checking again”. People get annoyed by obstacles without a reason.

My second rule: I give the confirmation screen more time than the other screens. The user stays there only a few seconds, but that's where the most expensive mistakes happen. When I review a fintech product in an end-to-end audit, I always test the transfer confirmation separately, with real amounts.