UK APP fraud reimbursement: who pays when an overseas fintech uses a UK EMI?
Who reimburses an APP scam when an overseas fintech offers UK accounts through an EMI, and how claims handling, indemnities and reserves should be agreed.
On the stated account structure, the United Kingdom (UK) electronic money institution (EMI) owes eligible customers reimbursement for qualifying outgoing authorised push payment (APP) scams involving transfers through the Faster Payments Scheme (FPS). When its programme receives a scam payment, the EMI owes the required contribution to the victim’s sending provider. The Kenyan fintech’s programme agreement determines a separate commercial exposure. It cannot remove the EMI’s regulated responsibility. (Payment Systems Regulator (PSR), Specific Direction 20 (July 2024), paras 3.1–4.1; Pay.UK FPS Reimbursement Rules, Schedule 4, version 4.0, rules 3.1, 3.5 and 5.1–5.7; Electronic Money Regulations 2011, reg. 36.)
The Kenyan business plans a branded app for UK sterling accounts supplied by the EMI. Its team will build the interface, collect onboarding information and provide first-line support and fraud-claim triage. Before accepting an indemnity for losses associated with programme customers, it needs an agreed claims procedure, access to evidence and a defined basis for each charge.
- Confirm the account provider and Faster Payments route before allocating either outgoing reimbursement or incoming contribution claims.
- Give the support desk a direct escalation route and preserve the original report time. Fund customer payments independently of disputes between programme partners.
- Negotiate specified loss categories, causation, recoveries and limits. Identify the legal character of every reserve and settlement balance.
- Approve the Kenyan functions, permissions and data-access arrangements before those staff handle live claims.
Identify the account and payment that triggered the claim
The APP fraud reimbursement rules protect individuals, qualifying microenterprises and qualifying charities. A microenterprise must employ fewer than ten people and have annual turnover or an annual balance-sheet total no greater than €2 million. The charity threshold is annual income below £1 million. A business account is therefore not automatically outside the scheme. Joint holders do not create a separate reimbursement limit for each name. (Specific Direction 20, para. 14.4; Specific Requirement 1 (July 2024), paras 4.4–4.5; Schedule 4, rule 4.4.)
Check the customer contract, account location, payment instruction and settlement record together. The payer must authorise the payment from a relevant UK account. The transfer must settle through Faster Payments and reach a relevant UK account outside that payer’s control. Fraud must have induced payment to an unintended recipient or for an unintended purpose. An account in the victim’s name can still be outside their control. The receiving account holder need not satisfy the payer’s protected-customer categories. (Schedule 4, rules 3.10–3.11 and definitions in section 10.)
A relevant account is held in the UK, supplied to a service user and capable of sending or receiving Faster Payments. The definition excludes accounts provided by credit unions, municipal banks and national savings banks. The customer’s residence and the app’s branding do not establish coverage. The mandatory regime covers qualifying payments executed from 7 October 2024. (Specific Direction 20, paras 3.2–3.3 and 14.4.)
An internal book transfer that never settles through Faster Payments falls outside this particular mandate. That does not decide contractual rights, Financial Conduct Authority (FCA) obligations or an ombudsman complaint. A transfer to an account the payer controls needs separate analysis of any subsequent scam payment. Card payments, cryptoasset transfers and international remittance legs require their own rules; any qualifying UK Faster Payments leg must still be identified. The Clearing House Automated Payment System (CHAPS) has a separate reimbursement regime. (Specific Direction 20, para. 14.4; Specific Direction 21; PSR PS25/5, chapter 5, questions 6–9.)
Allocate the provider’s decision and the support work
Trace the customer terms through the EMI’s permissions, any agency registration, the programme agreement and the indirect-access agreement. The responsible sending or receiving payment service provider (PSP) is the provider of the relevant account. An indirect participant remains responsible for its own covered accounts. Its access provider supplies the connection; the account it supplies to another PSP is not itself a relevant account merely because customer payments pass through it. (Specific Direction 20, paras 3–4 and 14.4; PSR PS25/5, chapter 5, question 2.)
Do not assume the access provider has no responsibilities. The scheme expressly addresses a sponsoring bank that controls the sponsored PSP’s access to claim funds. Obtain the access contract and identify who can release reimbursement liquidity. (Schedule 4, rule 2.5.) The wider provider-role analysis is developed in the guide to launching UK wallets through an EMI principal.
Keep three fintech roles distinct. A technology and support supplier can perform specified outsourced tasks. If it provides payment services on the EMI’s behalf, the relevant agent registration and customer disclosure must be in place. A separately regulated PSP needs its own permission and account-participation analysis. A UK technical-services exclusion depends on the actual activity, including never possessing transferred funds; it excludes payment initiation and account information services. (Electronic Money Regulations 2011, regs 26, 34 and 36; Payment Services Regulations 2017, reg. 138 and Schedule 1, para. 2(j).)
For this programme, assign intake, evidence collection and routine updates to the Kenyan team. Assign final eligibility, vulnerability, refusal, reimbursement funding and complaint decisions to named EMI owners. This is the recommended operating division. The EMI may delegate assessment tasks under controlled outsourcing, but its management retains compliance responsibility and its customer obligations remain. An indemnity supplies no defence to those obligations. (Electronic Money Regulations 2011, regs 26(2)–(3) and 36.)
Follow the claim and reimbursement sequence
Design one case record for both customer and provider communications. It should capture the first report, account and transaction identifiers, authorisation evidence, scam communications, warnings, vulnerability evidence, information requests, decisions, payments and recoveries. Give the EMI access throughout, including after programme termination. Directed PSPs must retain the required claim information and decision records for at least five years. Apply data-law safeguards to retention and access. (Specific Direction 20, para. 8.4; Pay.UK Compliance Monitoring Regime, version 6.0, section 4; Schedule 4, rule 4.10.)
For an outgoing claim, the procedure should follow this sequence:
1. Record the report immediately. A claim begins when the customer reports the scam with details identifying at least one payment. The support desk must not postpone that date until its evidence pack is complete. The claim must be reported within 13 months of its final scam payment; payments before 7 October 2024 remain outside the mandate. (Specific Requirement 1, paras 4.7 and 5.3; Schedule 4, rules 3.4 and 3.8.)
2. Notify the receiving PSP within two business hours. Supply the available payment identifiers, amounts, report time and proportionate supporting evidence. Scheme business hours run from 9 am to 5 pm on business days, excluding weekends and bank holidays in any part of the UK. (Schedule 4, rule 4.1 and section 10.)
3. Obtain the recipient-side evidence. The receiving PSP has a three-business-day opportunity to respond. The sending EMI cannot complete its assessment until that period expires or all receiving PSPs respond. It can reimburse earlier, but must still complete the required assessment before claiming a contribution. (Schedule 4, rules 4.2–4.3.)
4. Assess and normally reimburse within five business days. A pause requires a necessary information request for an allowed assessment purpose. Those purposes include eligibility, vulnerability, a representative’s authority, claimant-fraud evidence and information from other PSPs. An internal approval queue or an indemnity dispute is not a pause ground. (Specific Requirement 1, paras 5.1 and 5.4–5.6.)
5. Complete the assessment and pay or reject within the outer 35-business-day period. The two clocks run concurrently; a permitted pause does not extend that outer limit. Record the assessment and give written reasons. After a positive assessment, notify the receiving PSP(s) within one business day of completing it; after a rejection, notify them within one business day of informing the consumer. An unresolved internal investigation is not itself a substantive exclusion permitting refusal. (Specific Requirement 1, paras 5.7–5.9; Schedule 4, rules 4.9–4.14.)
The maximum mandatory reimbursement is £85,000 per claim before any permitted excess. The EMI may apply one excess of up to £100. Linked claims for the same scam share the cap and excess; these are not allowances per transfer. Materially affected vulnerable customers cannot be charged the excess, but the monetary cap and 13-month limit still apply. (Specific Requirement 1, paras 4.2–4.7, 5.2 and 5.20–5.21; PSR notices of value dated 25 September 2024 and 19 December 2023; Schedule 4, rules 4.4 and 4.15.)
For an incoming scam payment, the victim normally reports to their own sending PSP. The programme’s EMI must identify its receiving account, preserve records, supply relevant evidence and handle lawful recovery action. It should check the sender’s contribution request against the payment, assessment, actual reimbursement and required supporting data. A valid contribution is payable within five business days after the qualifying notification. Absence of fault by the receiving EMI is not a general defence. (Schedule 4, rules 4.2, 4.7 and 5.1–5.7.)
The usual contribution is half the required reimbursement, apportioned where several receiving PSPs are involved. A sender that waives an available excess cannot automatically charge half that concession to the receiver. Voluntary amounts and payments following a closed claim, including later court or ombudsman awards, do not generate the ordinary scheme contribution. Keep these amounts in separate contractual categories. Reconcile recovered funds against sums already paid so neither programme partner recovers the same loss twice. (Specific Requirement 1, paras 5.12–5.18; Schedule 4, rules 5.2, 5.5–5.6 and 6.1–6.4.)
Resolve disputed classifications and exceptions
A failed purchase does not automatically establish an APP scam. Investigate whether deception affected the recipient’s identity or the payment’s intended purpose. Genuine non-performance without fraudulent intent can be a civil dispute. Conversely, paying the intended supplier or receiving an initial service does not exclude a scam. Preserve the communications, representations, delivery evidence and information held by the receiving PSP. The EMI should record and explain any civil-dispute classification. (PSR, Supporting the identification of APP scams and civil disputes, September 2024, paras 1.2–1.8 and 2.1–2.29.)
An unauthorised payment follows a different legal route. Authentication alone does not necessarily establish consent. Under the Payment Services Regulations 2017, qualifying unauthorised transactions ordinarily require a refund by the end of the next business day after awareness, subject to the statutory conditions and exceptions. Do not automatically apply the APP claim’s five-day timetable. The guide to payment consent and refund routes explains the wider classification problem. (Payment Services Regulations 2017, regs 67 and 74–77.)
The consumer standard of caution covers relevant interventions, prompt reporting, reasonable information requests and the requested police-reporting cooperation. Refusal under that exception requires the sending PSP to demonstrate gross negligence in a relevant failure. Ignoring a warning alone does not establish it. Where vulnerability materially impaired protection against the scam, that exception is unavailable. Customer participation in fraud, dishonest claims and unlawful payment purposes require separate findings. (PSR Consumer Standard of Caution Exception, paras 1.5–1.7; associated guidance, paras 1.4–1.14; Schedule 4, rules 3.6 and 3.11.)
Run complaints alongside reimbursement. For payment-services and e-money complaints, the firm must normally send a final response by the end of 15 business days after the day it received the complaint. If exceptional circumstances beyond its control prevent that, it must send a holding response within the same period, explain the delay and give the final-response deadline. The final response must follow by the end of 35 business days after the day of receipt. Other complaints ordinarily have an eight-week timetable. Financial Ombudsman Service eligibility and respondent relationships must be checked separately; some victims can complain about a receiving PSP despite having no account with it. Scheme refusal does not determine every possible complaint outcome. The fintech’s indemnity dispute needs its contractual forum. (FCA Handbook, Dispute Resolution: Complaints sourcebook (DISP), 1.6.2R–1.6.2AR and 2.7.3R–2.7.9R.)
Negotiate the indemnity and reserve arrangements
The proposed “all fraud losses” indemnity could transfer exposures far beyond the fintech’s service failures. It might capture ordinary scheme reimbursement, receiving-side contributions, unauthorised payments, voluntary settlements, complaint awards, penalties and investigation costs. Those categories have different triggers. Association with a programme customer proves neither a breach by the fintech nor causation.
Start with a loss schedule distinguishing mandatory net scheme costs from losses caused by each party’s failures. The fintech should accept responsibility for proved losses caused by its agreed service breach, inaccurate information, missed escalation or staff wrongdoing, subject to negotiated limits. Reduce that responsibility for the EMI’s own causal failures and for recoveries. This is a proposed commercial position; the scheme itself does not require the technology supplier to fund every programme loss. (Specific Direction 20, paras 3–4; Electronic Money Regulations 2011, reg. 36.)
If the EMI requires the fintech to share ordinary reimbursement costs without fault, negotiate that obligation separately. Define eligible products, payment routes, loss categories, calculation, aggregate exposure and pricing. Give the fintech the evidence and operational influence needed to manage the exposure. Separate voluntary settlements and additional complaint or court payments, which may attract no receiving-PSP contribution. An indiscriminate indemnity can otherwise charge the fintech for decisions it could neither control nor inspect.
Require a documented claim package before an intercompany charge: the applicable obligation, decision, payment evidence, contribution calculation, alleged breach and causal link. Provide a challenge and escalation process. The EMI should control decisions needed to meet customer and regulatory duties; the fintech should receive consultation and defence rights over the separate indemnity claim. Its consent right must not delay mandatory reimbursement. Allocate settlement authority for voluntary amounts expressly.
Recoveries need a continuing ledger. Credit receiving-PSP contributions, returned funds, insurance proceeds and other compensation against the same loss, with later adjustments. State who pursues recovery and any assignment or subrogation rights, subject to customer entitlements and applicable restrictions. Define audit, cooperation, confidentiality, limits, insurance evidence and post-termination handling of outstanding claims. Avoid an indefinite reserve merely because a claim might someday arise. (Schedule 4, rules 5–6.)
For every reserve or deduction, identify the account holder, beneficial entitlement, purpose and legal basis for holding the money. A reserve funded from the fintech’s corporate cash, security over a commercial receivable, and safeguarded relevant funds have different consequences. Specify whether corporate security transfers title, creates a charge or is held under another arrangement. Address access on insolvency, permitted use, top-ups, statements, disputes and release.
Keep that security outside customer safeguarding arrangements. Relevant funds cannot finance the EMI’s own reimbursement exposure or the fintech’s indemnity. A clause referring to “settlement amounts” does not change their legal character. Where customer funds and commercial fees are mixed in a settlement calculation, redesign the funds flow and ledgers before permitting netting. (Electronic Money Regulations 2011, regs 20–21 and 24; FCA Handbook, Client Assets sourcebook (CASS), 15.2.1R.)
Amounts genuinely due and payable by a customer can affect that customer’s safeguarding balance under the applicable rules. That does not permit deducting the fintech’s debt from another customer’s money. Even a corporate-funded balance held as e-money needs classification before being treated as freely available collateral. The UK payment safeguarding review addresses the separate funds-flow and reconciliation work. (CASS 15.8.33R–15.8.34G.)
Approve the Kenyan operating process before launch
Document the functions performed in Kenya and the powers given to each team. An authorised EMI must notify the FCA of the intended outsourcing and comply with the additional conditions for important operational functions. Every EMI remains responsible for its outsourced activities. Its agreement should secure access to records, audit and regulatory cooperation, controlled subcontracting, incident escalation, continuity and exit assistance. Technical access must match the authority granted in the claims schedule. (Electronic Money Regulations 2011, regs 26–27, 31A and 36.)
Kenyan permission requires a separate determination. The National Payment System Act’s PSP definition expressly includes certain processing or storage of data for PSPs or payment-service users. Its authorisation prohibition concerns conducting PSP business in Kenya. The fintech therefore needs a documented assessment of its local business and actual functions, supported by its licence scope or other sufficient perimeter evidence. A UK supplier classification or EMI permission does not settle that question. Resolve any authorisation requirement before starting the relevant activity. (National Payment System Act 2011 (Kenya), ss 2 and 12–13; National Payment System Regulations 2014, regs 4–5.)
Map personal-data purposes and access in both directions. Where the Kenyan company processes only on the EMI’s instructions, use a processor contract covering instructions, security, assistance, subprocessors, audit and return or deletion. Separate overseas-company access to UK-held records requires the UK transfer analysis even if hosting remains in Britain. Put an appropriate transfer mechanism and the current statutory data-protection assessment in place. (UK General Data Protection Regulation, arts 28, 32, 44A and 46.)
The Kenyan company must also address local data law in its actual role. Financial-services processing is a listed mandatory-registration category, regardless of the small-entity thresholds. (Data Protection (Registration of Data Controllers and Data Processors) Regulations 2021, reg. 13 and Third Schedule, item 8.) Returning information from Kenya to the UK or allowing onward access requires a Kenyan transfer analysis. Vulnerability evidence can include health or other sensitive information. Processing sensitive personal data outside Kenya requires the data subject’s consent and confirmation of appropriate safeguards under section 49(1); health-data processing must also satisfy section 46. Limit access to what the task requires and resolve those conditions before sharing detailed medical evidence. (Data Protection Act 2019 (Kenya), ss 4, 18, 25, 30–31, 41–42 and 44–49.)
Approve launch against a signed claims responsibility schedule and the following evidence:
- Customer terms, the EMI’s relevant permissions and any required agent registration.
- Programme and indirect-access agreements identifying both PSP roles, funding authority and the applicable inter-PSP escalation arrangements.
- A funds-flow diagram distinguishing customer balances, commercial fees, reserves and reimbursement funding.
- A tested claims procedure covering both payment directions, vulnerability, refusal, complaints, records and current Pay.UK registration and reporting.
- Agreed loss definitions, evidence rights, limits, recovery credits and reserve-release terms.
- A Kenyan functions assessment and the required data-processing, access and transfer arrangements.
The recommended arrangement leaves the EMI funding and controlling its customer and scheme obligations, with the Kenyan team performing defined support. Allocate the fintech’s service failures by evidence and causation; price and cap any wider sharing separately. Revisit that allocation if the fintech supplies its own payment accounts, controls payment execution, changes customer categories or payment routes, or obtains broader access to sensitive evidence. Current Reporting Standard A obligations must be operational; proposed reporting or policy changes require a change process when adopted, rather than assumed implementation dates. (Specific Direction 20, section 9; Pay.UK Compliance Monitoring Regime, version 6.0, sections 4–5 and 12.)
Licentium can review the programme agreement, customer journey and claims responsibility schedule, including loss allocation, reserve terms and overseas evidence access. Review the programme agreement and fraud-claims responsibilities.
Related reading
UK business wallets for a Ghanaian fintech under an EMI principal
A Ghanaian fintech supplies the brand, software and customer support for business wallets. A UK electronic money institution issues the e-money and maintains the customer balance. The fintech also wants to onboard customers and quote foreign exchange. Those additional functions need an activity-by-activity allocation before the branded service launches.
Agentic payments and refunds for an AI shopping agent’s wrong purchase
A Singapore software company supplies an AI shopping agent to UK and EU consumers. It controls the model, prompts, merchant selection and transaction logs, while a regulated payment partner supplies the credential or initiates payment. In this hypothetical composite, the decisive question is whether a disputed purchase breached the shopping instructions, lacked payment consent, involved merchant non-performance, or combined those failures.
Philippine AI voice agents for UK payment customer support
A hypothetical Philippine supplier proposes an AI voice agent with human escalation for a UK-authorised payment institution. The service would answer inbound calls, retrieve permitted account information, explain approved material and record or transcribe conversations. Its software would run in a UK-hosted environment, with relevant records accessible to authorised Philippine staff. The recommended initial contract confines the supplier to controlled support and gives the payment institution effective control over customer treatment, data use and service changes.
Where to go from here
Try Licentium AI
Licentium's AI workspace for regulatory questions. Web3 and AI teams shipping fast.
Browse the Fintech Licensing Hub
Jurisdiction-by-jurisdiction guides on licensing pathways, timelines, and costs.
Talk to us
Describe your product and plans, and we will reply with the next steps for scoping the work.