How should a bank app design scam warnings and payee checks on legacy rails?
Payee-check results, scam warnings and new-payee friction work when each result has a clear screen, warnings match the payment, and the bank logs what the customer saw.
A payee check can return “close match,” a scam warning can be well worded, and the customer can still tap through both. An online experiment with a nationally representative UK sample of roughly 10,000 adults found that calls to action that let people cancel or postpone a payment cut fraud far more than warnings did. The effect of behavioral warnings had faded by the third scam scenario. It was an experiment, not a live bank, but it frames the right question. What does the screen let the customer do, and what does the bank record about it?
Humbleteam, a product design agency, publishes this guide. It draws on public rules and research from the UK, the EU and the UAE that you can read yourself, and it is general information, not legal advice. Your compliance team decides which rules apply to your product. The guide pairs with our guide to pending states and cut-off times on a legacy core, which covers how to show a payment that is waiting, and our 8-week pilot plan, which covers how to find out what your systems can return. This guide covers the checks and warnings themselves.
What do the rules ask of the screen?
| Rule | What it says | Status |
|---|---|---|
| UK Confirmation of Payee (Pay.UK) | The payer sees one of four results before paying: match, close match, no match or unavailable. The payee’s bank decides the result, per NatWest’s help page. | In use. The PSR said in 2024 that 350 more firms would join by the end of October 2024. |
| UK APP reimbursement (PSR) | Covers Faster Payments and CHAPS transfers between UK accounts made from October 7, 2024. Reimbursement within five business days, with the clock stoppable up to 35 business days. Optional excess up to £100. Cap £85,000. | In force. Frontier Economics’ evaluation came out July 1, 2026. The PSR’s roadmap plans a consultation in December 2026 and a decision in May 2027. |
| UK fraud delay, regulation 86 | A bank with reasonable grounds to suspect fraud may delay a payment to ask questions, for no longer than needed and never past the end of the fourth business day. It must tell the payer. | In force since October 30, 2024. |
| EU Verification of Payee | Euro-area banks must offer the check, free of charge, on credit transfers. Results: match, close match, no match or other. | Applies from October 9, 2025 in the euro area and July 9, 2027 in other member states. The EPC rulebook version 1.0 took effect October 5, 2025. |
| CBUAE Consumer Protection Regulation and Standards | Compensate customers for losses from financial crime unless gross negligence or fraud by the customer is proven (6.2.2.4). Run fraud awareness campaigns every year (Standards 6.2.1.6). Send timely notices when a fraud pattern appears (6.2.3.2). | In force. |
Two points matter more than the table. First, the other bank decides the match. NatWest’s help page and the EPC rulebook agree on that, so your app reports a result and cannot upgrade or downgrade it. Second, no result blocks a payment. NatWest says no payment happens without the customer’s confirmed instruction, and the EPC rulebook leaves the decision to proceed with the customer.
What about the UAE? We found no CBUAE or Aani document that defines match, close match or no match results for payee names. Vendor write-ups describe a May 2025 CBUAE notice (reference CBUAE/FCMCP/2025/3057) that covers payee name display and, for instant payments, name verification. We could not find that notice on the CBUAE rulebook, so we do not treat it as a rule here. Ask your compliance team for the text before you design to it. Two things we could read: CBUAE’s digital identity guidance lists registration of third-party payee details among high-risk activities where biometric authentication is advised, and the Standards (5.1.1.47) set a 30-day reimbursement window for unauthorized payments. We found no UAE text equivalent to the UK reimbursement rule. Whether clause 6.2.2.4 reaches a payment the customer authorized after being deceived is a question for your legal team.
What should each payee-check result say and do?
Fill one row per result, with compliance and your payments team in the room. The text and actions below are our suggestions, not requirements.
| Result | What the screen says | Default action | Override path | What gets logged |
|---|---|---|---|---|
| Match | “The name matches the account.” Say what was checked, never “safe.” | Continue | None | Result code, time, name typed, which service answered |
| Close match | Show the name the other bank holds and say it differs from what was typed. | Stop here. Offer “Use this name,” “Check with the payee” and “Cancel.” | Customer picks “Use this name,” or edits and re-checks | Returned name, typed name, option chosen, text version |
| No match | “The name does not match the account. The money may go to someone other than the person you meant to pay.” | Remove the one-tap path. Add a step that tells the customer to confirm by a number they already trust. | Customer confirms and continues. High-risk payments go to a hold. | Result, extra step shown, choice, time |
| Unable to check | Say the check could not run and why in plain words: timeout, other bank not covered, opt-out. Add “This does not mean the details are wrong.” | Same extra step as no match. Offer a retry. | Retry, or continue after confirming by a trusted route | Reason code, retry count, choice |
| No check on this payment type | Say this payment type has no name check, and name what the bank checks instead. | Lean on the purpose question and risk signals | None | Rail and a “no check” flag, so reports do not count it as a failure |
The EPC rulebook already requires part of this. For no match, unable to check and no response, the paying bank must tell the customer that authorizing may send funds to an account not held by the payee they named. On a close match it must show the name held by the other bank. If no answer arrives in 5 seconds, the paying bank reports that the check was not possible and may offer a retry.
Watch your no-match rate. The EBA’s practitioner note says customers who see “No match” or “Verification not possible” are often unsure whether it is safe to authorize, and that frequent mismatches from small naming differences, such as ABC Ltd against ABC Limited, can lead customers to ignore warnings. Aliases, truncated names and virtual accounts also produce false mismatches. Because the payee’s bank sets its own matching criteria, your inbound matching rules shape other banks’ customers too. Review them as well as your screens.
When should a warning be specific, and when is a banner enough?
The UK regulator’s guidance on the consumer standard of caution is the most useful text for a designer, even though it was written for reimbursement claims. It says interventions should be bespoke: specific to the customer, the scam type and the transaction, not “boilerplate.” A bank should not refuse a claim because the customer saw vague warnings, or warnings that routinely appear on most payments of a similar type. A written warning must be actively brought to the customer’s attention, and a notice on a public website does not count. The guidance also says a customer who proceeds after a warning is not automatically grossly negligent, and that a bank cannot hand the whole job of judging risk to the customer. Such rejections are rare: the PSR’s Q1 2026 dashboard shows about 2% of claims rejected for insufficient customer caution. The guidance is dated December 2023, and the PSR’s roadmap says it may consult on further guidance, so check the current text.
A generic banner on every payment fails that test. A warning chosen from signals does not. Our suggestions:
- Ask for the purpose in the customer’s words, with a short list: paying for goods or services, investing, paying someone I know, moving my own money, paying a bill or tax.
- Choose the warning from the purpose, the check result, whether the payee is new, and the amount against the customer’s history. Show it only at medium and high risk.
- Tell the customer what to do, not only what to fear: confirm by a number you found yourself, or save the payment for later.
- Vary the wording and layout over time, and show at most one warning per payment.
The evidence supports each point, with caveats. In the Nottingham experiment, the control group’s journey had 22% of participants fall for fraud, and a risk-based journey with cancel, postpone and call options cut that by 18 percentage points. Behavioral warnings alone had a smaller effect and lost significance by the third scenario. The risk-based approach without the new actions did not reduce fraud, but it raised completion of legitimate payments by 8 points. Lab research on security warnings found the same decay: repeated warnings drew less attention each time, and a design that changed its appearance held attention longer. That work covers app permissions, not payments, so treat it as a signal.
Where does friction help, and where does it cost you?
Friction is limited by law and costs completed payments. The UK rule above allows a delay only on reasonable suspicion, only for as long as the enquiry needs, and with notice to the payer. The PSR guidance adds that a bank should ask whether it should have paused a payment. In the UAE, Standard Chartered tells customers that transfers to a new beneficiary wait four hours, citing CBUAE Notice 2829.2024. We could not find that notice itself, so check the text and whether it covers your products. Our earlier guide shows how to display such a wait as a state with an end time.
The price shows in the same experiment. Adding cancel and postpone buttons alone cut fraud by 12 percentage points and cut completed legitimate payments by 14. Target friction at first-time payees and risk signals, not every payment. Offer three exits on every stop screen: cancel, save for later, and call the bank. The CBUAE Standards (5.1.1.43) require digital and phone channels for reporting fraud around the clock, so the call option should reach a live route.
What do legacy systems limit, and what can the screen promise?
The name check is a call to another bank, not a lookup in your core. The EPC rulebook gives the paying bank 5 seconds, preferably 1, and expects the service to run every day of the year. A batch core cannot hold that rhythm, so the call belongs in the channel layer or payment gateway. The same goes for risk scoring. If your core receives a payment only after the app releases it, and cannot recall or hold it afterward, the decision to warn or hold must come before release. Map this in the constraint map from the pilot plan: where each signal lives, how fast it answers, and what happens when it does not.
| The screen can say | The screen cannot say |
|---|---|
| A check ran, and what the other bank returned | That a payee is genuine or safe. Pay.UK’s FAQ notes the check does not guarantee a fraudulent payment will be caught. |
| A hold ends by a stated time, if your own process sets that time | That a payment can be recalled after release, unless the core can do it |
| What the customer can do next | That a claim will be paid. Gross negligence is judged case by case. |
The FCA’s Consumer Duty rules say communications must be likely to be understood and clear, fair and not misleading. “Verified” and “protected” promise more than a name check delivers.
Illustrative worked example: a first payment to a new payee at Bank A
Bank A is invented, and so are its rules. Its app calls a name-check service and a real-time risk service from the channel layer. The core receives a payment only after the channel releases it, and it cannot recall one. The check times out after 2 seconds.
| Moment | What the systems do | What the customer sees | What is logged |
|---|---|---|---|
| Enters details, picks “Paying for goods or services” | Name check returns close match with the name “Example Roofing Services Ltd” | “The name on this account is Example Roofing Services Ltd. It differs from what you typed.” Buttons: Use this name, Check with the payee, Cancel | Both names, result, text version |
| Taps “Use this name” | Risk service sees a new payee and an amount above the customer’s usual range. Score: medium. | One warning written for the purpose: deposits for work are a common scam setting. Confirm by a number you found yourself. Buttons: Continue, Save for later, Call us | Warning ID, shown time, risk score, signals used |
| Taps “Continue” | Channel releases the payment to the core | Status moves to “Sent” once the core accepts it | Choice, release time |
| Variant: the check times out | Result: unable to check | “We could not check this name. That does not mean the details are wrong. Confirm them by a number you trust.” The risk score rises one level. | Reason code, score change |
| Variant: score is high | Channel holds the payment before release | Hold notice with the reason, what the customer can do, and when the hold ends | Hold start, notice sent, outcome |
Two choices carry the design. The warning appears once, after the customer has dealt with the name, so it is not the third banner in a row. And every screen the customer saw is logged with its text version, because that record is the evidence if a claim later turns on what the bank showed.
Where do these defaults stop working?
The sources are regulator texts, a scheme rulebook, bank help pages and one experiment. The experiment used an online sample and a mock app, not live customers. Result wording in the UK comes from Pay.UK’s FAQ and bank pages, since Pay.UK’s own rule documents were not readable. The EPC rulebook is version 1.0, and the EPC may have published later ones. The PSR is reviewing the reimbursement rules. UAE notices cited by vendors and banks were not available in primary form. The guide does not cover business payments, card scams, crypto transfers or the engineering of real-time cores, and every piece of wording needs your compliance team’s approval.
What can you produce now?
Four things before anyone draws a screen: a filled result map for your two most common payment types, a purpose list with one warning per purpose and risk level, a log specification that records what the customer saw, and a test run in which the name service times out. Measure the share of each result, how often customers proceed after a warning, how often they cancel, and how many legitimate payments are abandoned. Watch each of those by how many warnings the customer has already seen.
If you are choosing a design team, give each candidate one row of the map and ask for the screen. Our comparison of design agencies used to bank compliance and legacy systems lists studios with published bank cases to start from.
