In the fintech failures described by regulators recently, the issue is not about the app screens. It is about handling money in the product - the mismatched balances, erroneous payments, and ineffective checks on customers. These are easier and less expensive to solve before the product launch than when actual customers are using the product.
That's why some teams prefer to consider them design issues rather than testing ones. Nomium, a tech company that provides software development services for fintech products (payment systems, digital banking and lending apps), usually starts the process with a discovery stage. Before coding starts, the team agrees with the client on which actions produce a financial record, what system stores each particular piece of information, and what happens if there is an error in it.
Here are five checks that use the same logic and can be applied by any team (in-house or external). They reduce the probability of a bad launch, but they do not replace advice from lawyers and compliance specialists because the legislation differs from country to country and from product type to product type.
1. Do your balances match the bank?
Every customer's balance in the product must correspond to the actual amount of money at your bank or partner bank. Otherwise, it becomes impossible to know who is owed what.
A clear example is the US company Synapse, which connected banks and fintech apps. According to the US deposit insurer, the FDIC, after Synapse declared bankruptcy, many customers could not reach their money for months. Even for the banks, it became hard to match the records of Synapse with actual balances.
In the UK, this kind of matching is now mandatory. Starting from May 2026, FCA regulations obligate payment and e-money companies to verify customer money against their own records every working day.
What to check: your system creates each balance using the whole history of the transactions, not a single value that overwrites the previous ones. A daily report compares the balances in the system with those in the bank, and a named person is responsible for fixing all the differences.
2. What happens when a payment goes wrong?
Real-life payments are not perfect. A request can time out and be sent again, so the customer may pay twice. A notification about a successful payment may come delayed, in duplicate or in the wrong order.
It is openly acknowledged by payment providers. For example, Stripe notes in its documentation that the same notification may come multiple times and the order of events cannot be guaranteed. Stripe also offers a special request ID that prevents a repeated request from being processed twice.
A payment that looks successful may also be returned. According to the regulations of Nacha, an organisation that establishes US ACH (Automated Clearing House) bank transfer rules, a customer's bank may return an unauthorised debit from the customer's account within 60 days. If your product pays out the money immediately after receiving the "success" status, you may lose that money later.
What to check: every payment has clear statuses, such as pending, completed, failed and returned. The team knows what the customer and support staff see in each case after testing repeated, delayed and out-of-order notifications.
3. Do your customer checks really work?
Having a written policy for customer checks does not mean having checks that work. This includes identity checks (usually called KYC), anti-money laundering checks and sanctions screening.
The UK regulator, the FCA, fined two digital banks for this reason. Starling Bank was fined about £29 million in 2024 because for years its automated system had been checking customers only against part of the sanctions list. Monzo was fined about £21 million in 2025, partly because it accepted customers with obviously unrealistic data, like famous London landmarks in the home address field.
In both cases, the regulator noted that checks were not able to keep up with fast customer growth. This is the real risk of a new product: what works for 1,000 users does not necessarily work for 1,000,000 users.
What to check: before the launch, run fake "bad" test customers through the real sign-up flow. For example, use a name that matches a sanctions list, an impossible address and unusual money transfers. Each of them should raise an alert that reaches a person able to take action. Estimate the number of alerts you will receive as you grow and confirm the exact rules for your market with your compliance specialist.
4. What if a key partner stops cooperating with you?
Fintech products depend on their partners: a bank, a banking-as-a-service provider, a card processor, or an identity check service. The failure of the partner or its decision to end the contract can make your product inoperable, even if there are no errors in your code.
The US banking regulators (the OCC, the Federal Reserve and the FDIC) pointed this out in their joint statement in July 2024. Among the risks they highlighted were operational problems, excessive reliance on one partner, confusion among customers and misleading information about deposit insurance. The Synapse case showed the main point: the failure of the only company that keeps records of whose money belongs to whom can freeze everyone else.
What to check: you can provide answers to three questions in writing.
- Who keeps the main record of each customer's balance?
- Do you keep your own up-to-date copy of it?
- What is the plan if the key partner fails, and does your contract grant you access to the data?
Also make sure that the information you give to customers about deposit protection corresponds to your actual legal arrangements, not to the marketing text of the partner.
5. Can one customer see another customer's account?
A common security problem in financial applications is unexpectedly simple. A user opens their account, replaces the account number in the request, and the system displays another customer's account. It happens because the system verifies the user's login but does not verify that the account belongs to this user.
OWASP, a well-known security community, puts this problem at the top of its 2023 list of the top ten API security risks. The same list mentions the risks of letting an ordinary user reach administrative functions like refunds or manual balance corrections.
What to check: create two test customers. Logged in as the second customer, try to open and change accounts and transfers of the first customer through the API, not through the app screens. Every attempt must fail. For your own staff, grant each role only the necessary access and require the approval of another person for manual money transactions.
Simple pre-launch checklist
Before you approve the launch date, ask the team to demonstrate the completion of each check. If something is still missing, this is the issue to discuss.
| Check | What can go wrong | What to ask for |
|---|---|---|
| Balances | Your numbers do not match the bank | Daily matching report and a person responsible for differences |
| Payments | Double charges or money paid out too early | List of payment statuses and tests of repeated or late messages |
| Customer checks | Bad actors get through as you grow | Results of tests of fake "bad" customers and an alert review plan |
| Partners | The product stops if a partner fails | Your own copy of balance records, a backup plan and contract terms on data |
| Access | One customer sees another customer's money | Test results with two accounts and a list of staff access rights |
What can wait and what cannot
A minimum viable product does not necessarily have all features, all markets or a good-looking admin panel. All these can be added later, when you already know how your users interact with the product. Nomium defines a fintech MVP in a similar way - a release that tests one particular workflow with a certain target audience while keeping the necessary controls.
Balance records, payment statuses, customer checks and access control are different. They influence every transaction from the first customer, so fixing them later requires fixing the past data, not adding a feature. There is a simple rule here: set the date of the launch when the checklist is ready, not when the feature list is.
