Fintech app design: trust, onboarding and compliance screens

Nobody gets excited about uploading a passport photo to a new app. In fintech, you ask people to do that, and then to link a bank account, and then to trust you with their money.

So the main design job is not decoration. It is to make each step feel clear, safe and worth it. Here is how we think about the main screens in a fintech product.

One note first. This is design guidance from a product studio. It is not legal or compliance advice. Rules differ by country and by product type, and your legal team or advisers decide what you must do.

Trust cues

Trust does not come from a padlock icon. It comes from many small signs that the product is honest and competent.

What helps in practice:

• Say who you are. Company name, the licensed partner bank or regulator where this applies, and a way to contact a real person. Put it where people look when they hesitate, such as the sign-up page and the footer.
• Explain why you ask. Next to every sensitive question, a short line: "We ask for your date of birth to confirm your identity." People give data more willingly when they understand the reason.
• Be exact about fees. Show them before the user commits, in plain numbers. Hidden fees destroy trust faster than any other thing in fintech.
• Use plain words. "Money in your account" is clearer than "available liquidity". Save the technical terms for people who ask for them.
• Keep the interface calm. Stable layouts, clear labels and no surprise pop-ups. A jumpy, noisy screen near a money action feels risky.

Only show badges and claims you can back up. A "bank-level security" label with nothing behind it does more harm than good. If you hold a certification, name it and say what it covers.

KYC steps

KYC means "know your customer": the identity checks many financial products must run. For users, it is the most annoying part of onboarding. Good design cannot remove the checks, but it can make them much easier to get through.

1. Show the road ahead. Before step one, list what you will need: "ID document, a selfie and proof of address. About five minutes." People who know what to expect finish more often.
2. Let people start before they verify. Where the rules allow it, let users look around, or set up a profile, before the heavy checks. Ask for identity only when they need to do something that requires it.
3. Break it into small steps. One thing per screen, with a clear progress marker.
4. Help with the camera. Photo capture is where many users fail. Show an example of a good photo, give live guidance ("move closer", "too dark") and let people retry without starting over.
5. Save progress. If someone leaves at step four, let them return to step four. Send a reminder email that links straight back.
6. Give a clear waiting state. If a check takes time, say how long it might take, what happens next and how they will be told.
7. Handle rejection with care. If a document fails, say why in plain words and what to do. "The photo was blurry. Try again in better light" is useful. "Verification failed" is not.

Test this flow with people on older phones and weak connections, and with names that have accents, long names or one name only. These are the cases that break forms.

Money screens

When a screen shows money, users read every word. Design for that.

Make amounts easy to read. Align numbers, use a clear currency symbol or code, and show decimals consistently. Use tabular figures in lists so columns line up.

Confirm before you send. A review step should show the amount, who receives it, which account it comes from, any fee and when it arrives. Put the final button text as the action: "Send $250.00", not "Continue".

Be exact about time. "Arrives today by 5 PM" or "1 to 3 business days" is better than "soon". If you do not know, say what affects it.

Show status after the action. A transaction might be pending, completed, failed or reversed. Each needs a plain label, a short explanation and, where it makes sense, a next step.

Protect against slips. A big amount, a new recipient or an unusual country can trigger an extra check. Keep these checks light, and use them where the risk is real.

Show balances honestly. If "available" and "pending" differ, show both, and explain the gap in a line.

Errors and holds

In fintech, something will go wrong. A card gets declined. A transfer is held for review. An account is locked. How you speak at that moment matters more than anything on the happy path.

Good error messages in this setting:

• Say what happened, in plain words
• Say whether the user's money is safe
• Say what the user can do now
• Say what the company is doing, and how long it may take
• Give a clear route to a human, such as chat, email or phone

Compare "Error 4012" with "Your transfer is on hold while we run a routine check. Your money is safe. We usually let you know by email within one business day. You do not need to do anything." The second one is longer. It also stops a support ticket.

Be careful with holds and blocks. You may not be allowed to explain every reason, and you should not guess. Your compliance team can help you write wording that is honest and within the rules. Do not let the screen say less than you are allowed to say.

Notifications

Notifications in fintech carry weight. They tell people money moved, a login happened or a payment failed. Too many make people ignore the important ones.

• Separate alerts from marketing. Security and transaction alerts should be on by default and hard to confuse with promotions.
• Put the key fact first. "You received $120 from Maria L." Not "You have a new notification."
• Let users choose channels. Push, email, SMS, with sensible defaults. Some alerts, such as security ones, may be required.
• Never put full sensitive data in a notification. Lock-screen previews can be read by anyone near the phone.
• Help users spot fakes. Tell them what you will never ask for, such as a password or a one-time code by message.

Working with legal

Designers and lawyers can work well together if they talk early.

• Bring legal in before the screens are final. A required disclosure is much easier to design in than to squeeze in after.
• Ask for the intent, not just the text. If you know why a disclosure exists, you can often present it more clearly while still meeting the rule.
• Keep a list of required elements per screen and market, so new designers do not remove them by accident.
• Test required wording with real people. If users cannot understand a consent screen, tell legal. There is often room to write the same thing more clearly.

We do not give legal advice, and we do not replace your compliance team. What we do is design the product around the constraints you are given, so that safe also feels simple.

If you are building a fintech product and want help with the main flows, see how we work with SaaS and fintech teams, look at our work, or read about the MVP design sprint. To get a quick outside opinion on one screen, such as your sign-up or KYC step, ask for a free design review at /contact.