From the journal

Deepfake detection from Malaysia for UK payment-fraud controls

A Kuala Lumpur supplier analyses live customer-call audio and optional video for a UK payment institution. Its deepfake detection score initially goes to a trained fraud team, while the supplier seeks training samples and later voiceprint matching. The launch decision concerns which data uses and payment controls the parties can lawfully support.

32 min read

Executive Summary

  • The Malaysian supplier should initially offer media-manipulation signals for a UK payment institution's human fraud assessment. The contract should exclude customer matching, automatic payment action and the supplier's reusable training unless the parties separately establish the conditions for those activities. A technical service without possession of funds can fall outside payment-service authorisation, but its actual functions determine that boundary (Payment Services Regulations 2017, Schedule 1, Part 2, paragraph 2(j)).
  • A voice recording is not automatically special-category biometric data under UK law. The technical unique-identification definition and the purpose of the processing matter. Malaysia's definition omits the UK identification requirement, so the same extracted characteristics can require different treatment there (UK GDPR, Articles 4(1)(14) and 9(1); Malaysian Personal Data Protection Act 2010, section 4).
  • The institution must choose a lawful basis for each purpose. The recognised legitimate interest for necessary crime detection carries a specific restriction: it cannot support significant solely automated decisions. Human review must influence the original payment decision, with authority to depart from the score (UK GDPR, Article 6(1)(ea), Annex 1, paragraph 5, and Articles 22A–22C).
  • Retaining calls for a supplier's general model usually makes the supplier a controller for that reuse. Neither a contractual data licence nor compatibility with fraud prevention alone establishes lawfulness. A commercial research argument requires the statutory research conditions and safeguards (UK GDPR, Articles 5(3), 8A, 28(10) and 84B–84C).
  • Identifiable access by the separate Malaysian company ordinarily requires a UK transfer mechanism even when servers remain in Britain. The parties must assess the actual access, onward uses and protection after transfer. Malaysian outbound rules require their own controller analysis (UK GDPR, Article 46; Malaysian Personal Data Protection Act 2010, section 129).
  • The payment institution retains responsibility for its customers and applicable operational controls. An authorised institution must assess whether this continuing service is an outsourced operational function and whether failure would make it important. A human final decision does not settle that classification (Payment Services Regulations 2017, regulations 25, 36 and 98).
  • A repeatedly flagged genuine customer needs prompt human investigation and an alternative authentication route. The institution must identify the legal basis for any block, refusal or delay. A spoof that passes requires a separate assessment of unauthorised-payment or authorised-push-payment reimbursement duties (Payment Services Regulations 2017, regulations 71, 75–76, 82 and 86; Payment Systems Regulator, Specific Direction 20, July 2024, paragraphs 3.1–3.3 and 4.1).
  • Procurement should specify separate false-positive and false-negative tests, controlled model updates, access to investigation evidence and an effective fallback. Liability clauses should allocate losses caused by each party's breach while preserving customer rights and regulatory responsibilities. No detection percentage establishes that a product is fraud-proof or regulator approved.

The supplier should sell a defined media-authenticity assessment with human review. Its output should identify the manipulation risk, input quality, uncertainty and model version. The institution should retain the payment decision and responsibility for alternative authentication. This proposed scope narrows the supplier's functions while preserving the fraud team's ability to investigate suspicious calls.

The service receives live audio and, when enabled, video. It extracts features and associates a score with a call or customer. Those operations can process personal data even when the supplier deletes the input immediately. Identifiability can arise through the institution's call identifier or transaction records, without the supplier receiving a customer's name (UK GDPR, Articles 4(1)(1)–(2)).

The initial release should disable optional video unless the institution can justify the additional information. Free-form calls can reveal health or other sensitive information independently of biometric recognition. The data schedule therefore needs instructions for incidental sensitive content, feature extraction and diagnostic access. A promise that every call contains only ordinary personal data would exceed the proposed design (UK GDPR, Articles 5(1)(c), 9(1) and 25).

The supplier's described activity can fall within the technical-service exclusion from payment services. That exclusion includes data processing, authentication and security support where the provider never possesses the transferred funds. Payment-initiation and account-information services remain outside that exclusion. The parties must reassess the perimeter if the supplier begins performing those functions; a contract describing a service as technical cannot determine its statutory status (Payment Services Regulations 2017, Schedule 1, Part 2, paragraph 2(j)).

Live capture also requires an interception analysis. The institution must map where content becomes available, who sends and receives it, and who controls the communications system. Where the UK interception rules apply, the parties need authority for the actual capture separately from their data-protection basis. The ordinary consent route requires consent from both sender and intended recipient. The business route requires express system-controller consent, an authorised purpose and communications relevant to its business on a system provided for those activities. It also requires all reasonable efforts to inform potential system users. Crime prevention or detection can qualify, subject to those conditions (Investigatory Powers Act 2016, sections 3–4, 44(1) and 46; SI 2018/356, regulations 3(1), 3(2)(e) and 4(1), as amended by SI 2019/742, regulation 133).

That assessment depends on the capture architecture. Processing content as an intended recipient differs from supplying a third party with a live feed. The parties should also assess the Malaysian capture under sections 4, 6 and 234 of the Communications and Multimedia Act 1998, including whether it is interception and whether lawful authority or the limited section 234(4) exception for service providers applies. Authority for operational fraud monitoring does not establish permission for the supplier's separate training purpose. The parties should resolve the capture and notice arrangements before introducing live customer calls.

Media manipulation and biometric identification

The institution should classify the actual features and purposes before accepting a claim that the detector avoids biometric rules. Under UK GDPR Article 4(1)(14), biometric data result from specific technical processing of physical, physiological or behavioural characteristics that allow or confirm unique identification. Article 9(1) separately restricts processing biometric data for the purpose of uniquely identifying someone.

A detector that examines synthesis artefacts without matching people can fall outside that biometric identification analysis. A recording alone does not satisfy every element. Yet a model can extract speaker-specific representations even when its interface displays only a manipulation score. Technical documentation should describe the representations, their persistence, their matching capability and their actual use. Marketing terminology cannot resolve those facts.

The proposed voiceprint extension changes the purpose. Comparing a caller against an enrolled customer's template verifies a particular person, even without searching a population database. Face-template verification raises the corresponding issue. The institution would need an Article 6 basis and an Article 9 condition for that recognition activity, alongside the remaining data-protection duties (UK GDPR, Articles 6(1) and 9(2)).

A manipulation score also cannot establish payment authorisation or criminal guilt. A genuine person may use altered media, while an impostor may use an undetected spoof. Recording a technical suspicion as an allegation of a criminal offence creates a further classification issue under Article 10 and the Data Protection Act 2018, sections 10(5) and 11(2). Case records should distinguish the observed signal, the analyst's assessment and any substantiated allegation.

Data roles and lawful purposes

The UK payment institution is the controller for its fraud-assessment purpose because it determines why the processing occurs and how it affects customers. The supplier can act as processor when it follows documented instructions for that service. The required processing contract must address instructions, security, confidentiality, other processors, rights assistance, deletion or return, and audit access (UK GDPR, Articles 4(1)(7)–(8) and 28(3)).

Technical discretion over implementation does not automatically create joint controllership. The relevant question is who determines the purposes and essential means of each operation. Institution-specific validation can remain processing on the institution's behalf. A supplier that chooses to retain calls for a reusable model ordinarily determines a separate purpose and becomes a controller for that use (UK GDPR, Articles 4(1)(7) and 28(10)).

The institution's UK establishment brings its processing within UK GDPR regardless of where the supplier works. The overseas supplier's own territorial position requires separate analysis. Supplying a UK business alone does not necessarily establish the supplier's direct scope under Article 3(2). Monitoring the behaviour of people in the UK can do so, with representative duties under Article 27 where applicable. The parties still need the processing and transfer terms required for the institution's use (UK GDPR, Articles 3, 27 and 28).

For necessary crime detection, the institution can consider the recognised legitimate interest in Article 6(1)(ea), read with Annex 1, paragraph 5. This route removes the ordinary legitimate-interest balancing test. Necessity, fairness, minimisation and any special-data conditions continue to apply. The institution must also account for the restriction on significant automated decisions under Article 22B(4).

Ordinary legitimate interests under Article 6(1)(f) remain a separate possibility, subject to the individual's interests and rights. A legal-obligation basis requires an identified obligation and processing necessary to comply with it. Regulatory fraud-control duties do not establish that optional video, indefinite retention or every proposed model feature is necessary. The supplier's commercial contract with the institution cannot itself satisfy the contract basis for processing a customer's data under Article 6(1)(b).

The data schedule should identify the chosen basis for operational scoring, investigation, quality assurance and any later reuse. Payment-services consent is another distinct requirement. Under regulation 97, a payment-service provider must have the user's explicit consent for access, processing and retention necessary to provide payment services. That contractual permission does not automatically provide UK GDPR consent for voiceprint enrolment or supplier training (Payment Services Regulations 2017, regulation 97; UK GDPR, Articles 4(1)(11), 6 and 7).

Retained calls and reusable model training

The supplier should exclude reusable training from the initial offer. Improving a model across customers can change the actor, purpose, retention period and consequences of processing. The institution should permit only specified validation and incident support under its instructions until the parties establish a separate lawful route.

Compatibility requires more than a shared fraud-prevention theme. Article 8A requires attention to the relationship between purposes, collection context, data sensitivity, possible consequences and safeguards, alongside its specific compatibility provisions. Under Article 5(3), compatibility alone does not establish lawfulness. The supplier must address the applicable Article 6 basis, any Article 9 condition, transparency and transfers for its own use (UK GDPR, Articles 5(1)(b), 5(3), 8A, 13(3) and 14(4)).

The supplier has a substantial counterargument where development qualifies as scientific research. Commercial funding does not exclude research under Article 4(2)–(3). The work must still be reasonably described as scientific. For Article 84B, the operation must collect the data, convert them into non-identifying information, or be necessary to fulfil the research purpose. Articles 84B–84C also require minimisation safeguards and exclude processing likely to cause substantial damage or distress. Those safeguards cannot be satisfied where processing concerns measures or decisions about particular data subjects, except for approved medical research.

A separated research programme can therefore require a different assessment from operational customer decisions. Special-category research also needs the conditions in Article 9(2)(j) and the Data Protection Act 2018, Schedule 1, paragraph 4, including necessity and public interest. Where the controller originally collected data on Article 6(1)(a) consent, Article 8A(4)'s narrower further-use rules apply; research compatibility alone is insufficient. Routine product improvement cannot acquire the research conditions through a label.

The preferred development inputs are appropriately licensed synthetic material and data demonstrated to be anonymous. Removing names while retaining identifiable voices or linkable embeddings leaves personal data. The contract should prohibit unapproved reuse, local copies and onward disclosure, then provide evidence of deletion. A broad intellectual-property licence grants no independent permission under data-protection law (UK GDPR, Articles 4(1)(1), 5 and 28(3)).

Conditions for enrolled voiceprints

The institution should procure voiceprint recognition as a separate capability. Explicit consent can support special-category processing where the customer has a real choice, receives clear information and can withdraw. An equivalent non-biometric authentication route would help preserve that choice. Making essential payment access depend on supposedly optional enrolment would weaken the consent position (UK GDPR, Articles 4(1)(11), 7 and 9(2)(a)).

Fraud prevention can also support a non-consent route, but only through a specific statutory condition. Under Article 9(2)(g) and the Data Protection Act 2018, section 10(3), Schedule 1, paragraph 10 requires necessary processing for preventing, investigating or detecting unlawful acts. Processing without consent must be necessary to avoid prejudicing that purpose, and the processing must serve a substantial public interest.

Covert assessment of a suspected fraudster presents a stronger no-consent argument than compulsory voiceprint enrolment of every customer. The institution must explain why the proposed recognition is necessary and why a less intrusive authentication process is insufficient. The separate fraud condition in Schedule 1, paragraph 14 concerns specified anti-fraud organisation sharing arrangements. An ordinary supplier relationship does not establish those arrangements.

The institution ordinarily needs an appropriate policy document for the relevant substantial-public-interest route. It must explain compliance with the data-protection principles and retention or erasure policies. The statutory retention requirement for that document does not create a minimum retention period for customer recordings (Data Protection Act 2018, Schedule 1, paragraphs 5 and 39–41).

Malaysia's processing and biometric rules

The Kuala Lumpur operation needs its own Malaysian analysis. Commercial processing by a person established in Malaysia falls within the Personal Data Protection Act 2010. UK-origin data do not escape that Act merely because the customers live abroad. A non-established controller using equipment in Malaysia for processing, beyond transit, can also fall within section 2(2)(b), with a representative requirement under section 2(3). The UK institution must therefore consider its own connection to the Malaysian processing.

Malaysia defines biometric data as personal data resulting from technical processing relating to physical, physiological or behavioural characteristics. Its definition contains no equivalent of the UK's unique-identification requirement. Biometric data are sensitive personal data under section 4. Features extracted from voices or faces can therefore engage Malaysian sensitive-data rules even where the UK identification test is not met. The parties should classify each feature against the Malaysian wording.

The 2024 amendments are operative. The biometric definition, direct processor security duty and revised transfer provisions took effect on 1 April 2025. The data-protection-officer and breach provisions took effect on 1 June 2025 (Personal Data Protection (Amendment) Act 2024, Act A1727, sections 3–6 and 12; P.U. (B) 522/2024, paragraphs (b)–(c)).

For processing subject to the ordinary principles, section 6 provides consent and specified necessity exceptions. It contains no general equivalent of UK legitimate interests. Section 40 ordinarily requires explicit consent for sensitive personal data unless a listed exception applies. Where section 7 applies, the notice must be in the national language and English. A UK lawful basis cannot replace these Malaysian conditions.

The crime exemption is a material qualification. Section 45(2)(a) exempts personal data processed for crime prevention, detection or investigation from specified principles and other related provisions. That wording supports an argument that the connected sensitive-data restriction is displaced for qualifying operations. Section 6(1)(b) expressly incorporates section 40, which is itself subject to section 5. The parties should document the particular crime purpose and the provisions they treat as exempt; declaring the whole business a fraud service would leave the separate training use unexplained.

General model development may serve purposes beyond the qualifying crime operation. The research exemption in section 45(2)(c) also requires exclusive research or statistical use and non-identifying results. Where neither an applicable exemption nor a section 40 exception covers sensitive processing, explicit consent remains necessary. Security, retention and data-integrity duties continue despite the specified crime exemption (Personal Data Protection Act 2010, sections 9–11, 40 and 45).

The supplier must comply directly with the Security Principle when acting as processor. Its own training purpose can make it a controller, with the corresponding additional duties. The parties should determine the applicable data-protection-officer appointment requirements under section 12A. Contract schedules should identify the responsible privacy contacts and the people authorised to investigate incidents (Personal Data Protection Act 2010, sections 4, 5(1A), 9 and 12A).

Access from Malaysia and transfers in each direction

The institution should treat identifiable access by the separate Malaysian supplier as an international-transfer issue. UK hosting alone does not remove that access. The assessment must cover support sessions, development copies, logs and access by other providers, as well as the live inference stream (UK GDPR, Articles 44A and 46).

Malaysia is outside the UK's current adequacy arrangements. The parties should use an available Article 46 safeguard, ordinarily a completed UK International Data Transfer Agreement for this UK-only export. A suitable EU contractual structure can instead use the UK Addendum with the correct underlying clauses. The institution must also satisfy the statutory data protection test; a signed form does not establish that result (UK GDPR, Article 46(1A), (2)(d) and (6)–(8)).

That test requires a reasonable and proportionate assessment of whether protection after transfer would be materially lower. The comparison concerns protection as a whole and the actual circumstances, including the data's nature and volume. The institution should examine access law and practice, enforceability, security, onward processing and the supplier's ability to comply. Identical foreign legislation is unnecessary, but encryption offers limited protection against access risks when overseas personnel can view the plaintext.

The offer should restrict named users and purposes, prevent unnecessary downloads, record privileged access and separate development from production. The institution needs suspension and exit rights when the required protection cannot be maintained. An alternative design can remove identifiable Malaysian access through genuinely anonymous inputs or operation within an environment inaccessible to the overseas supplier. Changing only the server location would leave the remote-access issue intact.

Malaysian outbound transfers require a separate allocation. Under section 129(2), a controller can transfer to a place with substantially similar law or an adequate level of protection at least equivalent to the Act. Section 129(3) provides alternatives, including specified consent, contract and reasonable-precautions routes. The former prescribed-country-list structure has been removed (Personal Data Protection Act 2010, section 129; Act A1727, section 12).

Under section 129, the controller bears the transfer duty. A supplier returning results solely as processor should not automatically be described as the exporting controller. The UK institution may itself have Malaysian obligations through its use of Malaysian equipment. The supplier becomes responsible for its own controller exports if it reuses data and sends them elsewhere. The data schedule should name the actor and legal route for each direction; a UK transfer agreement does not determine those Malaysian roles.

The institution's outsourcing and resilience duties

The institution should document the service's role in payment operations before deciding its outsourcing treatment. Regulation 25 requires an authorised payment institution to notify the Financial Conduct Authority of an intended outsourcing of an operational function. Additional conditions apply to important functions, where failure would materially impair compliance, financial performance or service continuity (Payment Services Regulations 2017, regulation 25(1)–(3)).

The supplier has a relevant objection to automatic classification. The FCA distinguishes operational functions from services outside payment services, including generic security services and standardised purchases. Continuing analysis of live customer calls within fraud triage presents a stronger outsourcing case because the supplier performs part of the institution's operational assessment. Dependency, scale and fallback determine importance; a human final decision does not by itself remove that dependency (FCA, Payment Services and Electronic Money: Our Approach, May 2026, paragraphs 4.58–4.61).

If the buyer is a small payment institution, regulation 25's authorised-institution notification duty must not be applied without a legal basis. Regulation 36 separately requires authorised and small institutions to take reasonable steps over functions performed by others and assigns responsibility for relevant acts and omissions. The institution cannot contract away its duties to payment-service users (Payment Services Regulations 2017, regulations 36 and 137).

Applicable operational-resilience rules require the institution to identify important business services, set impact tolerances, map dependencies and test disruption scenarios. The payment-institution scope includes small institutions, subject to the chapter's entity and activity scope. The institution should test detector outage, a surge in false flags, reviewer overload and an unsafe model update. Fallback must preserve secure payment access within the service's tolerance. An internal tolerance cannot extend a statutory payment deadline (FCA Handbook, SYSC 15A.1.1R, 15A.2.1R, 15A.2.5R, 15A.2.9R, 15A.2.10G, 15A.4.1R and 15A.5.3R).

The contract should provide evidence, access and cooperation sufficient for those duties. The FCA's October 2026 AI observations address effective human oversight, vendor changes and fallback, while expressly creating no new requirements (FCA, AI in financial services: good practice and areas for improvement, 19 October 2026, updated 20 October 2026, sections 1.2, 3.4 and 4.1–4.2). Licentium's Philippine AI voice agents for UK payment customer support examines the adjacent outsourcing of customer interaction.

Deployment evidence and customer safeguards

The institution should complete a data protection impact assessment before introducing this live fraud assessment. New technology, systematic evaluation and consequences for access to money support treating the proposed deployment as likely to create high risk. Human decision-makers do not remove Article 35's separate test. Residual high risk that cannot be reduced requires prior consultation under Article 36 (UK GDPR, Articles 35(1), 35(3)(a), 35(7) and 36(1)).

Acceptance should measure false alarms among genuine calls and missed attacks separately. Tests should use the intended channels, compression, background noise, languages and deployment population. Held-out attacks should include unfamiliar synthesis methods, replay and attempts to evade detection. The institution should require documented provenance for test data and protect them from training contamination. These recommendations implement accuracy, fairness, security and design duties; the legislation supplies no universal detector accuracy percentage (UK GDPR, Articles 5(1)(a), 5(1)(d), 25 and 32).

Aggregate accuracy can conceal harm when attacks are uncommon. A supplier should report the proportion of flagged calls that are actually attacks, the prevalence used in testing and uncertainty around each estimate. Review capacity matters because an acceptable laboratory false-alarm rate can create a queue that prevents urgent payments. The parties should agree acceptance thresholds against the deployment and customer consequences, then monitor drift and retest material updates.

Tests should examine whether channel or speech differences burden particular customers. For services in Great Britain, indirect discrimination requires attention to group and individual disadvantage, subject to justification as a proportionate means of achieving a legitimate aim. Disability adjustments create a separate duty. The institution should provide an accessible alternative authentication route and assess representative performance without collecting protected-characteristic data without a lawful basis (Equality Act 2010, sections 19, 20 and 29; UK GDPR, Articles 6 and 9).

Retention should follow each purpose. The proposed default is transient inference without a supplier training archive. A controlled incident extract may be retained where necessary for investigation, with access restrictions and an identified deletion event. The institution should set justified periods for scores, decisions and audit evidence. Neither the model-development ambition nor a possible future dispute justifies retaining every raw call indefinitely (UK GDPR, Article 5(1)(c)–(e); Personal Data Protection Act 2010, sections 10–11).

Customers should receive concise information about the purposes, relevant data uses, recipients, transfers, retention and rights. The institution can explain the role and consequences of a score without publishing exploitable detector details. For the UK crime exemption, restricting those rights requires the statutory prejudice test. The existence of fraud controls does not suspend all transparency or challenge duties (UK GDPR, Articles 13–16, 18 and 21; Data Protection Act 2018, Schedule 2, paragraph 2).

Automatic payment action under the amended UK rules

The automatic-blocking variant requires a new decision design. Since 5 February 2026, Articles 22A–22D govern significant solely automated decisions under the amended UK GDPR. A decision is solely automated when there is no meaningful human involvement in taking it. Legal or similarly significant effects engage the regime; the duration and practical effect of an urgent-payment hold matter (Data (Use and Access) Act 2025, section 80 and Schedule 6; SI 2026/82, regulation 2).

For the initial human-reviewed service, analysts must assess other evidence and have time and authority to change the proposed action. A preselected outcome, routine approval or inaccessible escalation route would weaken that position. An appeal after an automatic block supplies later intervention but does not change how the original decision was taken (UK GDPR, Articles 22A and 22C).

The recognised crime interest creates a specific constraint. Article 22B(4) prohibits significant solely automated decisions where any processing by or on behalf of the decision-maker for that decision relies on Article 6(1)(ea). The institution cannot retain that basis throughout the decision process and introduce automatic refusals merely by changing a contract clause. Ordinary legitimate interests remain subject to their own necessity and balancing assessment.

Special-category processing creates another restriction. Under Article 22B(1)–(3), a significant solely automated decision involving such processing requires one of two routes. The entire decision-processing activity must have explicit consent; alternatively, the decision must be necessary for the customer's contract or required or authorised by law, with Article 9(2)(g) satisfied. Consent to a voiceprint alone does not establish consent for all processing behind the automated decision.

Current UK law permits some significant automated decisions using ordinary personal data. Article 22C still requires information about the decision and means to make representations, obtain human intervention and contest it. Payment-law conditions and customer-treatment duties continue to govern any resulting hold or refusal. The supplier should require a separately agreed release before its scores can trigger automatic payment action.

The genuine customer's urgent refused payment

The institution should immediately route the repeatedly flagged genuine customer to an analyst with authority to resolve the payment. Repeating the same detector challenge can reproduce the error. The analyst should consider independent authentication, urgency and the reasons for previous flags, then record the basis for the action. A low score on a fresh attempt should not be the only route to review.

The institution must identify which payment power it is exercising. Under regulation 71, a payment instrument can be stopped where the framework contract reserves that right and the statutory grounds exist. Relevant grounds include reasonable security concerns or suspected unauthorised or fraudulent use. The institution must notify the payer before stopping, or immediately afterwards if prior notice is impossible, subject to the specified security and legal exceptions. It must restore use or replace the instrument as soon as practicable once the grounds cease (Payment Services Regulations 2017, regulation 71(2)–(6)).

A refusal to execute an order engages regulation 82. The institution must notify the user promptly and within the applicable execution period, unless notification would be unlawful. It must give reasons where possible and, where those reasons concern factual matters, explain how to correct errors. Where the payer's framework-contract conditions are met, the account-servicing provider cannot refuse an authorised order unless execution would be unlawful. A detector flag therefore needs assessment against the actual refusal ground (Payment Services Regulations 2017, regulation 82(1)–(5)).

The extended fraud-investigation delay is narrower. It concerns qualifying authorised sterling payments wholly within the UK, excluding payee-initiated transactions. The institution needs reasonable grounds to suspect fraud or dishonesty by someone other than the payer and must need the delay for enquiries. It must establish those grounds by the end of the business day after receipt of the order. A genuine customer merely misclassified as the fraudster does not automatically satisfy that test (Payment Services Regulations 2017, regulations 85(1A) and 86(2A)–(2D)).

The delay must last no longer than necessary for the enquiries and end by the fourth business day after receipt. The institution must notify the payer as soon as possible and by the end of the next business day, except to the extent notice would be unlawful. Notice must explain the delay, its reasons and any required information or action. The institution must compensate relevant charges or interest caused by the delay, including where it ultimately does not execute the payment (Payment Services Regulations 2017, regulations 86(2C)–(2D) and 94A).

These delay provisions took effect on 30 October 2024. Users outside the statutory consumer, microenterprise and charity categories can agree to disapply the extended-delay and related compensation provisions. The institution should identify the customer's category and terms before applying that exception (SI 2024/1013, regulations 1–2; Payment Services Regulations 2017, regulation 63(5)(a)).

For retail business within the Consumer Duty, the institution must address foreseeable harm and provide support that meets customers' needs. The urgent customer's loss of access and repeated unsuccessful challenges require assessment under those duties. Payment-services complaints ordinarily require a final response within 15 business days after the day of receipt. Exceptional circumstances beyond the firm's control can permit a final response within 35 business days, with a reasoned holding reply by the first deadline. Those periods do not justify postponing urgent operational help (FCA Handbook, PRIN 2A.2.8R, 2A.6.2R and DISP 1.6.2AR).

The institution should correct an inaccurate fraud allegation and annotate the historical score as an erroneous inference. Preserving the original technical output can support audit, provided the record explains its status and prevents repeated misuse. Restriction while accuracy is checked may also apply (UK GDPR, Articles 16 and 18).

A qualifying private person can claim for loss caused by breach of Parts 6 or 7 of the payment regulations, subject to statutory defences. The institution should promptly assess the urgent customer's actual costs and appropriate redress. A false flag alone does not establish breach, loss or causation, and compensation for a qualifying delay remains a distinct route (Payment Services Regulations 2017, regulations 94A and 148).

The spoof that passes the detector

The institution should investigate a successful spoof without treating the detector's pass as proof that the customer authorised the payment. Under regulation 75, recorded use of an instrument does not necessarily prove authorisation or fraud by the customer. It also does not necessarily prove an intentional or grossly negligent failure to comply with the customer's instrument-security duties. An unauthorised transaction ordinarily requires a refund by the end of the next business day after awareness, subject to the statutory conditions (Payment Services Regulations 2017, regulations 74–77).

The classification changes where the real customer was deceived into authorising a transfer. Eligible Faster Payments authorised-push-payment scams fall within the applicable reimbursement rules. Eligibility depends on the payment, customer and other scheme conditions; the rule does not reimburse every loss involving synthetic media. The institution must assess the current scheme requirements independently of any claim against the supplier (Payment Systems Regulator, Specific Direction 20, July 2024, paragraphs 3.1–3.3 and 4.1; Pay.UK, FPS Reimbursement Rules, Schedule 4, version 4.0, dated 1 May 2026).

Supplier liability requires a separate examination of the promised service and the cause of loss. A sophisticated missed attack can occur despite performance within an agreed test. Liability becomes more plausible where the supplier breached a measured commitment, concealed a known limitation or introduced an unapproved change that caused the failure. Institutional thresholds, human conduct and other controls can also affect causation. The institution should resolve customer entitlements while preserving its evidence for contractual recourse.

Incidents, complaints and access to evidence

The parties should operate a shared escalation process for security failures, severe false results and model deterioration. A wrong classification alone is not automatically a personal-data breach. The UK statutory definition requires a security breach affecting personal data. The institution must investigate accuracy, customer harm and operational disruption even where that definition is not met (UK GDPR, Articles 4(1)(12), 5 and 32).

For a UK personal-data breach, the controller must notify the regulator without undue delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to risk individuals' rights and freedoms. A likely high risk requires notification to affected individuals without undue delay, subject to Article 34(3)'s exceptions. A processor must inform its controller without undue delay; it has no independent 72-hour allowance (UK GDPR, Articles 33–34).

Malaysia's section 12B requires a controller to notify the Commissioner as soon as practicable when it has reason to believe a breach occurred. A breach that causes or is likely to cause significant harm requires notification to the affected individual without unnecessary delay. The contract should require the supplier to escalate promptly in either role and provide the facts needed for each controller's assessment (Personal Data Protection Act 2010, section 12B).

On becoming aware of a major operational or security incident, the institution must notify the FCA without undue delay. If the incident has or may have an effect on users' financial interests, it must also inform them without undue delay. That information must explain the incident and measures users can take to reduce its adverse effects. A new UK regime for operational-incident and material-third-party reporting takes effect on 18 March 2027. The contract should provide for those requirements where applicable when they become operative (Payment Services Regulations 2017, regulation 99; FCA 2026/6, paragraph C and relevant Handbook amendments).

Each investigation should preserve the input provenance, model and threshold versions, output, analyst actions and payment outcome under a justified retention schedule. Access rights should permit the institution, its auditors and competent regulators to examine relevant evidence, with secure protection for proprietary methods. The institution should keep a separate customer complaint route. Current data-protection complaint duties require acknowledgement within 30 days and appropriate handling and an outcome without undue delay (UK GDPR, Article 28(3)(h); Data Protection Act 2018, section 164A).

Vendor liability and the commercial contract

The supplier should commit to a specified service, documented limitations and measurable acceptance criteria. The agreement should allocate control over thresholds and payment actions to the institution, while assigning model operation and agreed support to the supplier. Changes to models, features, access locations, data uses or automatic actions should require notice, evaluation and the agreed approval process before release (UK GDPR, Articles 28 and 35(11); Payment Services Regulations 2017, regulations 25 and 98).

Remedies should address the breach that each party can control. Useful provisions include reimbursement of reasonable investigation and restoration costs, responsibility for unauthorised reuse, cooperation on customer redress, and termination for repeated material failures. The parties should negotiate caps, any separate limits for privacy or confidentiality breaches, and the treatment of third-party claims. Service credits should not become the only remedy for serious data misuse or an inability to provide the agreed service.

An indemnity for every fraud loss would ignore whether the supplier caused the loss. An exclusion covering every missed spoof could remove the commercial value of the promised performance. The agreement should specify causation, recoverable categories, mitigation, claims control and contribution where institutional decisions also caused harm. Statutory customer rights and regulator powers continue regardless of that allocation (Payment Services Regulations 2017, regulations 36 and 137; UK GDPR, Article 82).

For an applicable English-law business services contract, reasonable care and skill can supplement express promises. That standard does not guarantee detection of every attack. Misrepresentation remedies can arise where an inducing statement, reliance and resulting loss satisfy the applicable test. The parties should preserve the statements and test evidence used in procurement (Supply of Goods and Services Act 1982, sections 12–13 and 16; Misrepresentation Act 1967, sections 2–3).

The institution should not assume that choosing English law subjects every liability cap to statutory reasonableness. Section 27(1) of the Unfair Contract Terms Act 1977 disapplies specified controls where UK law applies only by choice and foreign law would otherwise govern. The service-provider connection under Rome I can make that qualification material here. Standard-term, international-goods and intellectual-property provisions require separate attention. Measured contractual protections remain necessary (Unfair Contract Terms Act 1977, sections 2–3, 11 and 26–27, Schedule 1, paragraph 1(c); assimilated Regulation (EC) 593/2008, Articles 3–4).

The institution should also secure continuity assistance, usable records and deletion or return on exit. It needs an alternative fraud-assessment process before suspension or supplier failure interrupts payment services. The supplier's audit and exit commitments should cover the other providers it uses for the service (UK GDPR, Article 28(3)–(4); FCA Handbook, SYSC 15A.4–15A.5).

Marketing claims and release conditions

The supplier should describe what the detector measures and the conditions of its tests. A claim of being biometric-free would require analysis under each relevant definition and of the features actually processed. Fraud-proof language would promise an outcome unsupported by this case. Regulator-approved language would require an actual approval covering the claimed product and use. UK-facing business advertising is subject to the statutory misleading-advertising test, including its effect on traders' economic behaviour (Business Protection from Misleading Marketing Regulations 2008, regulation 3).

The initial commercial package should contain a service specification, purpose-by-purpose data schedule, processing and transfer terms, acceptance plan and incident procedure. The supplier should support transient audio analysis, with video disabled unless separately justified. The institution should receive an explainable signal and uncertainty information, while trained analysts retain the payment decision. Reusable training, identity enrolment and automatic payment action should require separate contractual release conditions.

The implementation sequence should begin with lawful test data and an assessment of the actual features, roles and capture architecture. Before live calls enter the service, the institution should complete its impact and transfer assessments, establish the Malaysian processing route and implement customer notices and escalation. Live testing without payment consequences still requires lawful data processing. Customer-facing use should follow acceptance testing and a demonstrated alternative route when the detector or review team cannot provide the agreed service (UK GDPR, Articles 5, 25, 28, 35 and 46; Personal Data Protection Act 2010, sections 5–12B, 40, 45 and 129; Payment Services Regulations 2017, regulation 98).

Voiceprint matching requires a new biometric assessment, lawful enrolment and withdrawal or alternative-authentication arrangements. Automatic blocking requires a new decision-basis assessment, the safeguards under Article 22C and payment-law controls. The contract should prevent either expansion through an ordinary model update, and the institution should reopen acceptance testing and its impact assessment before enabling it (UK GDPR, Articles 9, 22A–22C and 35(11)).

More from the journal

See all

Software escrow for South African AI supplied to an Irish bank

A Cape Town AI supplier offers source-code escrow to an Irish bank that depends on its fraud-alert service. The bank needs a way to continue operating after supplier failure, but the software also depends on licensed model technology and cloud services. A workable arrangement requires a recoverable deployment, permission to operate it and an alternative when a necessary dependency cannot survive the supplier.

AI debt collection from India and the UK authorisation boundary

A Pune company supplies an AI debt collection system to a UK consumer-credit lender authorised by the Financial Conduct Authority (FCA). The system drafts reminders, schedules contacts and proposes repayment options, while the lender approves customer communications and decides forbearance. The supplier wants a later version to contact borrowers and negotiate within lender-set limits. The recommended first release keeps collection activity with the lender; the supplier-operated version needs a different permission and operating structure.

Crypto Travel Rule failures between a Brazilian provider and an Irish CASP

A Brazilian virtual-asset provider wants to transfer business customers' crypto-assets to an Irish crypto-asset service provider, or CASP. The assets reach the receiving address with incomplete originator information and a legal-entity name that does not match the recipient account. The sender demands immediate release because the blockchain transfer is final. The Irish receiver should hold customer availability while it resolves the identities and missing data, then make a documented release or return decision.