Facial Recognition Payments and DPIAs: Lessons From Revolut’s Pay With Smile Trial

You order a coffee, look at the payment terminal and the purchase is complete: it is easy to see the appeal. But before offering that convenience, an organisation needs to understand what happens to the face used to authorise the payment.

Revolut’s Pay with Smile trial brings that question to an everyday purchase: it is a useful example of why changing how customers pay can introduce a very different use of their personal information.

For organisations considering biometric payments, a Data Protection Impact Assessment (DPIA) should inform the design before launch.

Revolut’s Facial Recognition Payment Trial

On 24 September 2026, Revolut announced a Pay with Smile pilot at selected Kiss the Hippo cafés in London. The announced trial ran from 24 to 26 September.

According to Revolut, enrolled customers could authenticate payments through its Revolut Register using facial recognition. Its announcement described checking customers against the selfie ID checks completed when they joined Revolut. Customers opted into the feature through its app. Revolut’s announcement.

For a customer, the purpose is straightforward: paying for a purchase but for a data protection team, the underlying processing needs closer examination.

Introducing a different way to authenticate a transaction may change the information collected, the organisations involved and the potential consequences for individuals.

Photographs and Biometric Recognition Are Not the Same Thing

An ordinary photograph is not automatically special category biometric data.

The distinction depends on the technical processing and its purpose. Where facial information is technically processed to uniquely identify someone, it constitutes special category biometric data.

This includes verification, checking that someone is who they claim to be, as well as identification, establishing who they are. Describing a product as an “authentication tool” does not remove the need to understand its biometric functions. ICO guidance on biometric recognition.

For privacy professionals, this means looking beyond the procurement description. A payment terminal proposal may also involve cameras, biometric references, remote processing and additional records.

DPIAs Belong Before Deployment

Article 35 UK GDPR requires a DPIA before processing likely to result in high risk to people’s rights and freedoms. The ICO says organisations must complete one before using a biometric recognition system, explaining that this processing is highly likely to trigger the requirement. The same guidance emphasises privacy by design, including consideration of less intrusive alternatives. ICO guidance on biometric accountability.

The practical lesson is to involve privacy colleagues while the project can still change. Waiting until equipment has been purchased and a launch date announced limits the assessment’s usefulness.

A DPIA should explain the processing, assess necessity and proportionality, identify risks to individuals and set out measures to address them. A persuasive commercial case does not, by itself, establish that the processing is lawful.

Necessity and Proportionality Need Evidence

A useful assessment begins with the problem, not the preferred technology.

Shorter queues, improved accessibility and fraud prevention are different objectives. Each needs an explanation of how the proposed system helps and what alternatives are available.

For a biometric payment proposal, a project owner should explain the benefit compared with cards, phones or other authentication methods. The comparison should address privacy impacts as well as operational advantages.

This does not mean biometrics are automatically disproportionate. It means the organisation should be able to justify its choice.

For day-to-day work, request a short written business case before reviewing lengthy supplier documentation. It provides a clear reference point for assessing whether each proposed use of information is necessary.

Reusing Onboarding Data Needs Its Own Assessment

The reference to existing selfie ID checks raises an important question for any similar project: what permits information collected for account opening to be used for payments at a café? Already holding an image does not establish permission for a new use. Assess purpose limitation, the legal basis for the proposed processing and what customers have been told.

Also establish how the system finds the right account. Comparing a face with one specified reference is different from searching across a gallery of enrolled users. Both can involve special category biometric data, but the data flows, false-match risks and safeguards may differ. Do not infer the architecture from the word “authentication”.

Map Information Across Its Full Lifecycle

Avoid treating all facial information as one category with one retention period.

Revolut says temporary checkout facial embeddings are deleted after matching, while images and other records have separate retention arrangements.

Its notice distinguishes freezing the feature, which retains data, from withdrawing consent, which triggers deletion of the relevant biometric template.

Those statements do not establish that all related information disappears on withdrawal. They are published descriptions, not independently verified findings. Pay with Smile privacy notice.

For a proposed deployment, request a record of:

• Enrolment images and reference templates.
• Transaction photographs and temporary matching data.
• Payment, device and diagnostic records.
• Fraud investigation and dispute information.
• Supplier copies, backups and deletion arrangements.

For each category, establish its purpose, location, access permissions and retention period.

Where withdrawal ends consent-based processing, stop that processing. Retention for another purpose needs its own justification, a defined period or meaningful criteria, and an Article 9 condition if the retained use remains special category processing. Do not quietly switch legal basis to continue the same activity after consent is withdrawn.

A statement that information is deleted “immediately” is only useful when it identifies exactly which information it covers.

Lawful Basis and Special Category Conditions Need Separate Attention

Biometric recognition requires an Article 6 lawful basis and an Article 9 condition for special category processing.

A legitimate interests assessment does not replace an Article 9 condition. A contractual relationship also does not automatically justify every use of biometric information.

The ICO explains that explicit consent is often the most appropriate special category condition for biometric recognition. If another condition is proposed, check every requirement, including any applicable DPA 2018 Schedule 1 safeguards. ICO guidance on lawful biometric processing.

Our practical recommendation is to document the legal position purpose by purpose. Separate identity matching from fraud investigation, diagnostics and any proposed secondary use.

This helps expose assumptions that permission for one activity also covers another.

Customer Choice Must Work in Practice

Consent must be freely given, specific, informed and demonstrable. Explicit consent needs an express statement of agreement; merely looking at a camera does not establish it. Withdrawal must be as easy as giving consent. ICO guidance on lawful biometric processing.

Any discounts or loyalty rewards also deserve attention. An incentive does not automatically invalidate consent, but assess its value and context, whether refusal unfairly disadvantages people and whether a suitable non-biometric option remains available. Record that assessment rather than assuming that an opt-in button settles the question.

Test the actual customer journey rather than reviewing the consent wording alone.

Can someone decline at a busy checkout? Do staff understand the alternative? Can a customer distinguish pausing a feature from withdrawing consent?

Privacy information must also be clear and accessible at the appropriate time. The ICO recommends considering how people interact with the technology when deciding how to explain the processing. ICO guidance on biometric transparency.

A short explanation at the terminal, supported by fuller information elsewhere, may be more useful than relying on a lengthy notice alone.

The Camera Also Needs Boundaries

Check when image capture starts, what the camera can see and whether anyone else enters the frame. A person in the queue has not consented simply by standing near the terminal. Minimise incidental capture and separately assess any processing of bystanders or customers who have not enrolled. A sign explains processing; it does not supply consent.

Set limits on future uses too: payment authentication should not quietly become customer tracking, marketing profiling or model training. Each proposed additional use needs a fresh assessment of purpose, lawfulness and transparency, and fresh consent where required.

Accuracy and Fairness Require Real-World Testing

Biometric matching is probabilistic. A system may incorrectly accept someone or fail to recognise the correct person.

The consequences depend on the setting, the system’s configuration and the safeguards available. The ICO advises examining real-world performance, potential discrimination and the effects of matching errors. ICO guidance on fair biometric processing.

Ask for false acceptance and false rejection rates at the intended operating threshold, with evidence for the expected users and conditions. A claim of “99% accuracy” tells you little without its test conditions. Assess who might be wrongly charged, repeatedly rejected or embarrassed at the till, and how they obtain help.

Revolut describes alternative payment options after unsuccessful matches and a support route for contesting rejection and seeking human review. Pay with Smile privacy notice.

These published arrangements illustrate why fallback processes belong in the assessment alongside technical performance.

Security Requires More Than an Encryption Statement

Privacy and security teams should examine access controls, key management, template protection, retention and incident handling.

The ICO recommends considering protections that make templates harder to reverse engineer or link across different databases. It also stresses regular testing and appropriate organisational controls. ICO guidance on biometric security.

Test attacks using photographs, video or other impersonation methods, as well as the process for investigating and correcting an incorrect charge. Ask whether a compromised template can be revoked and replaced. Encryption alone does not answer these questions.

Our recommendation is to distinguish supplier assurances from supporting evidence. Record unanswered questions and assign an owner to resolve them.

Similarly, “not stored on the terminal” does not establish that information is absent from remote systems, support tools or backups.

Establish Responsibilities and Operational Readiness

Do not assume every supplier is a processor. Establish which organisation determines the purposes and means of each processing activity, and document the resulting responsibilities. ICO guidance on biometric accountability.

The contracts should reflect those roles, including Article 28 terms for processors or Article 26 arrangements where organisations are joint controllers. Identify hosting locations, subprocessors and overseas access, and address restricted international transfers where applicable.

Privacy professionals also need workable arrangements for access requests, complaints and withdrawal.

The ICO explains that biometric rights requests may involve samples, templates and technical formats. Organisations need processes to recognise requests and respond appropriately. ICO guidance on biometric rights requests.

Before launch, test who obtains supplier-held records, who handles complaints and how deletion instructions are verified.

Assess automated decisions separately under the current UK GDPR framework. The additional rules concern solely automated decisions with legal or similarly significant effects, with stricter conditions for decisions based on special category data. Consider the actual effect of payment approval or rejection and the available alternatives; not every failed match meets that threshold.

Pilots Still Need a Documented Launch Decision

A short trial involves real people and real information. Calling a project a pilot does not automatically exempt it from DPIA requirements.

Before launch, agree who can authorise the trial, what must be resolved first and what would make it stop. Examples include an incorrect charge, repeated failures affecting a group of users, or deletion not working as promised. Assign owners and set a review date.

Seek the DPO’s advice where one is appointed. The controller remains accountable for the processing. Where high risk remains that cannot be sufficiently reduced, prior consultation with the ICO is required before processing begins. ICO DPIA guidance.

Where appropriate, seek the views of affected people or their representatives as part of the DPIA. Feedback from people who decline biometric payments can be as useful as feedback from enthusiastic participants.

Keep the assessment under review. Expansion to new locations, changes to suppliers or additional purposes may alter its conclusions.

The Practical Lesson for Privacy Professionals

A good assessment should let the project team answer an ordinary customer’s questions: who gets my image, why do you need it, what happens if the system gets it wrong, and what remains when I stop using it?

If those answers depend on assumptions or unanswered supplier questions, there is more work to do before launch.

The most useful DPIA changes decisions while there is still time to change the system.

FAQs

Do Facial Recognition Payments Need a DPIA?

The legal requirement applies where processing is likely to result in high risk to people’s rights and freedoms. The ICO’s biometric guidance tells organisations to complete a DPIA before using biometric recognition and explains why these systems are highly likely to trigger the requirement.

Is Every Photograph Special Category Data?

No. An ordinary photograph is not automatically special category biometric data. The technical processing and its purpose matter. Using biometric information to uniquely identify someone, including verification, brings it within special category processing.

Does Explicit Consent Replace a DPIA?

No. Consent and a DPIA address different obligations. Consent does not remove a required assessment or make otherwise unlawful processing acceptable.

Can an Organisation Rely Entirely on a Supplier’s DPIA?

Not automatically. Supplier evidence can support an assessment, but the organisation must address its actual use, responsibilities and operating environment.

Does Deleting a Facial Template Mean All Related Information Is Gone?

No. Photographs, enrolment references, logs and transaction records may have separate retention arrangements. Establish exactly what is deleted and what remains.

Are Small or Temporary Trials Exempt?

There is no automatic exemption simply because processing takes place during a pilot. The proposed processing and likely risks determine the requirements.

Does Every DPIA Need ICO Approval?

No. Organisations do not routinely submit every assessment. Prior consultation is required where high risk remains that cannot be sufficiently reduced before processing.

Practical DPIA Support

Assessing new technology can involve incomplete supplier information, technical detail and competing delivery priorities.

Data Protection People offers DPIA support to help organisations assess proposed processing and identify practical next steps.

Contact our team to discuss your project.

Sources

• Revolut announcement
• Pay with Smile privacy notice
• ICO biometric recognition guidance
• ICO valid consent guidance
• DUAA automated decisions amendments