Introduction
When users first use an app, they may exhibit forgiveness for the app’s early stage; forgiveness can extend to missing features, basic dashboarding functions, and sluggish onboarding processes when a user’s understanding of why/detail around this exists. In contrast, users seldom show forgiveness when faced with uncertainty about how/where their money is being handled, who they are, or how secure the solution is.
Therefore, the importance of a trust-building/user experience within fintech (financial technology) becomes apparent when the user links their bank account, verifies their identity, transfers money, reviews a fee, or waits for an outgoing transfer to settle – at any of these timesa user is askingg themselves “Do I know what’s happening?” and “Do I feel safe continuing?”
If the end-user’s interface provides a clear answer to this query, the level of user confidence builds. If it does not, the user abandons the experience, generates support tickets, and causes damage to the Fintech’s reputation.
This is why, for fintech founders and product managers, developing fintech applications for functionality delivery must become more than just building out feature sets; communicating clearly with the end-user via the interface now becomes a core part of the solution set, thus the foundation upon which trust-building in a fintech solution is created can be accomplished through the following: Visible system status, clear error recovery processes and transparent confirmation steps rather than hidden logic or ambiguous messages. The Nielsen Norman Group’s usability guidelines, which include using simple language error messages and clarifying system status updates, emphasize utilizing these communication principles to facilitate user understanding of what their next steps will be.
At Appricotsoft, we treat that clarity as part of delivery quality, not decoration. It fits how we work in Unison Framework too: visible progress, visible risks, explicit decisions, and quality built into the process instead of being postponed until launch.
Below are the UX patterns that most consistently build trust in fintech products, along with practical examples and a simple do/don’t guide for each.
How UX Trust Differs in Fintech
Though poor design can be frustrating for users of most products, the impact of bad UX in fintech products is far more significant. Unlike frustrating messages that users of social networks receive when things do not work as expected, cardholders who receive vague error messages like “Something went wrong” while executing a financial transaction risk believing their money has gone missing or that their private information has been mishandled.
Fintech users continually make decisions involving high financial stakes. Examples include:
- Is this fee appropriate?
- Did my payment go through?
- Why do I have to provide this document?
- Is my account secure?
- Should I attempt this transaction again, or will I be double-charged?
When bad UX prevents the user’s ability to make a decision regarding these types of transactions, the interface must do a better job of providing the user with the necessary information to alleviate any concerns they may have. A high level of trust through UX must exist, so that users can advance through their experience by knowing what is occurring at the time, the reason for what is occurring, and what to expect when finishing their task.
This is especially relevant for users when using any form of authentication for transaction verification and payment processing. 3-D Secure authenticates card transactions and ensures that the individual making the transaction is the cardholder. When executed properly, this additional level of verification builds user confidence during the checkout process. However, when executed poorly, 3-D Secure can cause users to abandon their purchase because the transaction has been represented to them as erroneous.
1. The fees to show to clients before making a commitment, rather than after a commitment has been made
Nothing undermines trust quite like hidden fees.
Services should identify any possible fees associated with their products, i.e., transferring funds, obtaining foreign currency, issuing a card, charging any inactivity fees, charging a cash-out fee, and charging for any premium plans, before a user makes a commitment to the transaction. Although hidden fees may increase short-term transaction volumes in certain products, in the fintech sector, they generally decrease long-term trust.
The following amounts should be clearly displayed before the final step in the process:
- amount being sent or requested
- fee amount
- exchange rate, if applicable
- estimate of time for delivery
- the final amount the recipient gets or the user pays
- explanation of why the fee was paid
For example:
Instead of:
Continue with the transfer
Use:
You will send €100, the transfer fee will be €1.20, the recipient will/bank will receive €98.80, and it is estimated to arrive at 17:00 today.
Conveying this will create a more consistent experience in an emotionally charged transaction.
To do:
Provide total fees before final tap (final approval) on the review screen when the user is confirming the transaction.
To not do:
Provide a fee after authenticating the user, or communicating it through a tooltip.
A founder should consider this as retention UX, rather than just compliance UX, because customers who understand the fees will have a higher likelihood of completing the next transaction with you as well.
2. Confirmation Screens in Fintech
Fintech needs to provide closure to its users. After completing a transaction or performing some type of action, like transferring funds to a different account or setting up a new recurring payment, users may not feel like they have closed the item and may need to check back and confirm that their initial action was completed. The terminology used for confirming the successful completion of a user’s transaction can be important. For example, “Submitted” is a term that does not provide enough trust to a user; there are other terms like “Success” that will provide more support for trust, but can still require additional context to provide complete trust for the user.
A well-designed confirmation experience should include four pieces of information regarding the confirmation of the successful completion of the user’s last action.
- What happened?
- When did it happen?
- What needs to be done next?
- Where can I find a record of the completion of my last action?
An example of a good payment confirmation is:
“Funds have been transferred. The amount of €2500 will be transferred to Acme Supplies today. The expected delivery is in 1 business day. You will be able to find a record of this transaction by going to Payment History. Transaction ID: TRX4821.”
Providing this type of transparency will help users refrain from attempting to redo their transaction, refresh their screen, and/or contact customer service to verify that their transaction has occurred.
Use Confirmation to Reassure the User;
Do Not End an Important User Flow with a Generic Toast Notification That Disappears After 3 Seconds
This is one of the easiest ways for fintech software companies to provide an upgrade in trust and usually results in an immediate decrease in the number of customer support inquiries.
3. Design error handling to recover confidence, not just report failure
To foster user trust, your product must keep them informed. By providing some degree of certainty to your users during their experience with your product, they’ll be more likely to trust you.
This also applies to any process that has multiple steps or that has time delays, and it’s a great way to allow your users to feel in control while they’re waiting for something.
More specifically, for any flow that has multiple steps or time delays, provide the following information to your users:
- What their current status is.
- What steps have they completed?
- What step are they currently on?
- What they can expect for the next step in the process.
- If possible, provide an estimate for the length of time required for completing each step in the process.
- What they can or cannot do while waiting for the next step in the process.
For example, for a KYC process, let users know that:
- You’ve uploaded the user’s documents.
- A review of the user’s identity is currently being conducted.
- A check for compliance is pending.
- The user’s account has been activated.
Then tell the user:
“On average, most reviews take about 10 minutes to complete, while some require a manual review of up to 1 business day. We’ll send you an email once your account has been activated.”
This will not only set expectations for the user but also demonstrate that you are a company committed to providing a superior level of service.
What works:
Use specific language and make reasonable estimates of when your users’ requests will be fulfilled.
What won’t work:
Using false assurances like “We’re almost there…” when your system has no idea when it will be finished.
The trust created between a business and its customers will increase if a business is honest with its customers.
4. Create error recovery that builds confidence rather than just reporting failures.
In fintech, users are already stressed out when something goes wrong. The design of errors will help lessen this anxiety and provide direction for what to do next.
When designing error messages, the best ones are specific, human-like, and actionable. They describe exactly what went wrong in plain English and provide a suggested remedy. This is directly in line with good usability principles; see the following section for examples.
Good example
A good fintech error state includes:
- Headlines that are clear about the error
- Identifying what the error is
- An explanation of why you received this error
- Indication of whether any money has been moved
- Indicating the safest course of action for the next steps
- Indicating where to go for support if your error requires that level of assistance
Bad example
“Your transaction has failed!”
Better example
“We could not complete this bank transfer because the recipient’s account details were not in accordance with the bank’s format. Your account will not be charged. Please verify the IBAN before attempting to send again.”
By including ‘your account has not been charged’ in your message, you may prevent a support call.
Do:
Include what happened to the funds; e.g., captured, reserved, refunded, or untouched.
Do not:
Require a user to read between the lines to determine the financial implications using technical jargon.
Do not create an atmosphere of hostility or blame in your copy. A product developed for building trust will never make a user feel stupid for making an honest mistake.
5. High-Risk Actions Must Have a Review Screen
Some actions require friction to occur.
Not every flow must only require 1 tap. High-consequence actions can benefit from having a deliberate review step before completion in Fintech. Some examples include:
- Large Transfers
- First Beneficiaries
- Recurring Payments
- Closing Accounts
- Cancelling A Card
- Changing Payout Details
- Increasing Limits
- Sending Crypto
An effective review screen serves to prevent the user from experiencing regret, rather than slow them down.
What good looks like:
Provide a structured summary with individual editable sections, such as:
- Recipient
- Amount
- Fee
- Speed
- Funding Source
- Reference
- Security Method
Then use a strong call-to-action (CTA):
Confirm Transfer Not Next
Do:
Use the language/labeled CTA to match the actual action being taken by the user.
Don’t:
Conceal critical fields within collapsed accordions immediately prior to confirming information.
When a user is moving funds, clarity should always prevail over minimalism.
6. Make KYC verification transparent to the user, not intrusive
When KYC, AML, sources of funds checks, and identity verification processes are involved, there can be a great deal of mistrust in the fintech user experience. A consumer is frequently asked to submit personal information, documents, photos, and even additional pieces of evidence, but they generally do not understand the reasoning behind these requests.
This is why transparency is essential.
What good looks like
It’s important to provide a clear understanding of:
- Why is the information being requested
- How long does the process typically takes
- what types of documents can be provided
- how the data will be used
- what will happen if the consumer is asked to provide additional evidence, or if the review fails
Example
“We are required to verify your identity to safeguard your account, protect our company from regulatory issues, and for compliance purposes. The majority of verifications will take less than 10 minutes. Please provide one of the following: a valid passport, national ID, or driver’s license.”
This approach is calm, easy to understand,d and respectful.
Do
Explain the reason for the request prior to requesting that they upload documents.
Don’t
Drop consumers into a document upload screen without any explanation.
The same principle applies to Payment Authentication flows. If a consumer is redirected to an additional verification step, such as 3D Secure, there should be a clear and concise statement that indicates that the additional verification is solely for the purpose of providing them security, not for any other purpose. Stripe has documented that these flows are specifically designed to improve the company’s overall security posture and also meet regulatory requirements (such as Strong Customer Authentication).
7. How to Avoid Duplicating Requests in the Payment Flow
A main reason why user trust in a payment flow can be lost is due to uncertainty for the user whether they will be charged a second time if they click the same button again within the payment flow.
This can occur if:
- After the user submits their payment, the CTA remains active.
- The spinner is either not present or lagging.
- A processing-in-progress state is not clear.
- Clear handling of retries is missing.
- Network latency is misinterpreted as a failure to process.
When a user has made their payment:
- Disable any repeated submission of the payment.
- Provide a persistent and clear processing in-progress state for the user.
- Clearly communicate whether the user can safely exit the app while the payment is processing.
- If the user has lost connection, clearly communicate to them what steps to take next, and how to verify what happened at the end of the payment process.
- Retain the status of the user’s payment if they return to the app.
As an example of communicating the user’s payment status while processing a payment:
“Your payment is processing. Please do not leave the app. If your connection drops, your payment can be verified in your activity.”
This is a clear and simple way to help eliminate panic in payments.
What you should be doing:
- Designing for the fact that mobile users will experience uncertainty.
- Do not make the assumption that the ideal path will maintain the user’s trust with the application.
This is where cooperation between product teams, engineering teams, and the UX team is vital. The trust of UX is not just a design consideration, but also a system-wide consideration.
8. Use accountable language
Fintech apps want to present themselves as “clean and modern,” but they often come off as “vague.”
Accountable products use an appropriate tone that resonates with a sense of responsiveness rather than one that feels stiff and cold.
Accountable products provide:
- No fluffy buttons (e.g., Your Request is Being Processed)
- No ambiguous status (e.g., Pending)
- No ambiguously defined abbreviations (e.g., AP)
- No compliance terms without translation
- No misleading assurances
Improved Language Examples
Instead of “Your request is being processed.”
Say “We are reviewing your identification documents now.”
Instead of “Pending”
Say “Waiting on bank confirmation.”
Instead of “Action Required”
Say “Please upload a second identification document to complete the verification process.”
Good UX copy will reduce cognitive load for users at their point of greatest vulnerability.
9. Consistency Builds Trust Throughout The Entire User Experience
Trust is built as a series of cumulative steps.
For example, having a visually appealing onboarding screen will not make up for confusing payment states; being transparent about your fees does not compensate for an unclear account verification process; having a great confirmation screen won’t make up for having poor handoffs in support.
The way a user perceives your product will be the same from:
Onboarding → setting up a new account → verifying the identity of the user → funding their account with money → making payments → setting limits for payment processing → receiving notifications regarding their transactions → receiving support when they need it.
This is why we encourage product teams to think about how they design trust behaviour as a system (not as individual UI elements). In other words, have shared components (KVS), use similar terminology (naming conventions), apply common logic (decision tree), apply common review patterns (completeness vs accuracy), and develop a reusable framework for reporting errors with customers (error reporting).
As part of this type of disciplined delivery, for example, demoing software each week and being able to reference a single source of truth allows teams to discover trust gaps early on, before those gaps become costly product debt. One of our goals at Appricotsoft is to create software that allows us to build honest, quality-based relationships with users.
A user experience checklist of basic trust for business founders
While reviewing a fintech product, consider asking the following:
- Are fees clearly visible before users make a commitment?
- Are there reliable confirmation states for every critical user action?
- Are waiting states clearly communicated to the user?
- Is there clear communication of how and what error recovery will occur?
- Are there review processes for high-risk actions?
- Is there an explanation for why sensitive data is required in the verification process?
- Is the user able to identify if a payment is still processing, failed, or completed?
- Is there clear and accountable language used to communicate when a payment is being processed, will fail, or has been completed?
If the answer to any of these questions is “not consistently”, trust is leaking from somewhere along your customer journey.
For a more thorough view of how to successfully bring products from launch to maturity in your organization, please refer to our related roadmap to safely scale fintech products. If you would also like to review trust from a security standpoint, please refer to our secure by design guide
Utilizing external guidance can also prove beneficial; for example, while the usability heuristics created by the Nielsen Norman Group continue to guide practical improvements with system feedback and recovery patterns, you may also wish to reference Stripe’s 3D Secure documentation when creating a payment authentication flow for end-users that strikes a balance of security and clarity.
Conclusion
Trust in fintech app development is achieved through many little interactions with users, all identical to their last screen.
Customers gain trust based on the previously mentioned factors, and so too will customers trust your company’s fintech application.
With our expertise at Appricotsoft, we focus on developing applications that are transparent, reliable, and have the user experience designed around making it simple for your customers to accomplish their financial goals.
If you are considering developing a new application or improving an existing application, investing in a trust-based user experience will yield great returns over the long term.