# The Voice at Checkout: Authentication, Trust, and the Human-Centric POS Canonical: https://deriss.com/articles/the-voice-at-checkout-authentication-trust-and-the-human-centric-pos Description: A research report on voice biometrics, payment security, and the future of everyday commerce. --- ## Executive finding Voice can make a checkout easier to understand and, for some people, easier to use. It can recognise a request, help explain a basket, or provide a potential additional authentication factor. It should not replace the card, wallet, issuer, acquirer, or payment rails that carry and authorise the transaction. A person saying “pay” is not, by itself, evidence that the right person has approved the right payment. The defensible proposition is therefore narrower than a voice-only point of sale: an **optional, deliberately activated voice interface**, with clearly displayed transaction details, payment-provider-controlled authentication, proportionate step-up, and an equally usable non-voice fallback. Speaker verification and anti-spoofing require their own evaluation; neither turns speech recognition into payment security. This report synthesises primary research and European legal provisions. It is not a report of a deployed Deriss payment system, a Stockholm trial result, or a legal opinion. The proposed pilot below is a research protocol, not an announced partnership. The cited evidence is strongest for controlled speaker-verification and spoof-detection tasks. Evidence that the same systems remain secure, inclusive, and useful at a busy physical checkout is materially weaker. ## Five decisions that must not be collapsed into one **Command recognition** asks what was said: “show the total”, “use this card”, or “cancel”. It can work without establishing who spoke. An accurate transcript can still contain an unauthorised command. Cashier speech, a nearby customer, or a recording must not become a transaction instruction simply because the recogniser understands it. **Speaker verification** asks whether a sample matches a particular claimed identity, usually one-to-one against an enrolled template. It is probabilistic, threshold-dependent evidence, not certainty about a person. It differs from searching a population to identify an unknown speaker. A voice-based checkout should not quietly cross that boundary. **Liveness and anti-spoofing** ask whether the sample or interaction is consistent with a live, legitimate user rather than replay, synthesis, voice conversion, or another presentation attack. A speaker match can be produced by an attack. Conversely, an anti-spoofing pass does not prove the speaker is the account holder. A prompted phrase can help establish freshness, but is not a guarantee against interactive synthetic speech or a compromised capture path. **Payment authentication** establishes the payer through the payment provider’s permitted process. Strong customer authentication, where required, involves the legally defined factor combination and its independence—not merely a confident voice match. A biometric may be a candidate inherence element in an appropriate implementation; that does not make a microphone, model, and voice command a complete SCA system. **Payment authorisation** is the separate decision to approve and execute the payment through the issuer and payment infrastructure, subject to account, risk, and transaction controls. An authenticated customer can still have a payment declined. Recognising a command, matching a speaker, and authorising funds are distinct events that should remain distinct in the system and in its audit trail. A practical flow preserves those boundaries: deliberate activation; clear basket, merchant and total; a proposed action; customer confirmation; the provider’s authentication or exemption decision; payment authorisation; and an unambiguous receipt or decline. The interface must never announce “paid” merely because a biometric test passed. ## What the research actually demonstrates Reynolds and Greenberg’s [NIST-listed chapter, Voice Biometrics: Future Trends and Challenges Ahead](https://www.nist.gov/publications/voice-biometrics-future-trends-and-challengesahead), [DOI 10.1049/PBSE012E_ch10](https://doi.org/10.1049/PBSE012E_ch10), frames the field around reliability, privacy, acoustic variability, and increasingly sophisticated attacks. It is a research chapter, not NIST certification of a retail payment product. Its relevance is the challenge set: performance depends on capture conditions and adversaries as well as the voice model. > **[Locked preview — full framework available in the complete version.](/experience-layer)** ## Threat model: a voice is reproducible, not a secret Replay is the simplest warning: a genuine recording can match its speaker while being entirely unauthorised. Synthetic speech and voice conversion add further routes to imitating speaker characteristics. An attacker may have recordings from public media, calls, or previous interactions; a design should not assume that the customer’s voice is unavailable to others. Fresh challenges, controlled capture, presentation-attack detection, and binding a session to the intended transaction can reduce particular risks. None should be advertised as making a voice “uncloneable”. The model must consider attacks on the microphone and capture software, relayed interactions, compromised devices, altered transaction details, and recovery or enrolment abuse—not just a loudspeaker playing yesterday’s phrase. A stolen biometric template is especially consequential because a person cannot replace their natural voice in the way they replace a password. Templates should be protected with access controls, encryption, separation from payment credentials, and, where feasible and evaluated, revocable or transformed representations. Template protection reduces exposure; it does not make the template anonymous or guarantee that a breach is harmless. The merchant should not receive a reusable voiceprint merely to complete a sale. The preferred boundary is a narrowly scoped authentication result from an accountable provider, with minimal necessary transaction metadata. Failed voice attempts should move to a safe alternative or step-up process rather than silently lowering the threshold to clear a queue. ## European payment law: inherence is not the whole system [PSD2 Article 97](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02015L2366-20250117) sets SCA requirements for specified actions, including initiating an electronic payment transaction. Article 97(2) adds dynamic linking to a specific amount and payee for **electronic remote payment transactions**. These provisions must not be collapsed: physical card-present payments are not generally outside SCA, but they must not automatically be treated as remote e-commerce transactions either. The [Regulatory Technical Standards on SCA, Regulation 2018/389](https://eur-lex.europa.eu/eli/reg_del/2018/389/2023-07-25/eng), address inherence, independence of elements, and specific exemptions, including contactless payments at the point of sale. Whether an exemption applies is a payment-provider decision under the applicable rules, not something a merchant’s voice interface can declare. A contactless exemption does not validate the security of a separate voice-biometric mechanism. A voice biometric is a potential inherence element only within an implementation that meets the applicable requirements. The provider must assess the reliability of the element, the combination with another qualifying factor where SCA is required, and independence against compromise. A recorded phrase is not automatically a knowledge factor, and a voice sample plus another measurement of that same voice should not be assumed to be two independent factors. The [EBA Q&A 2020_5353, On the requirements for “inherence” in strong customer authentication](https://eba.europa.eu/single-rule-book-qa/qna/view/publicId/2020_5353), is a relevant implementation reference. Its substantive final answer could not be independently retrieved for this report; no numerical threshold, specific approval of voice, or compliance conclusion is attributed to it. The operative legal analysis here rests on PSD2 and the RTS, and deployment requires the payment provider’s current assessment. Whatever the legal classification of a particular transaction, the human interface should show the merchant, amount, currency, and intended payment method before confirmation. Spoken readback can supplement that display but must not replace it for everyone. Changed totals, ambiguous commands, suspicious activity, or uncertain verification should trigger renewed confirmation or provider-controlled step-up. A voice result should not silently authorise a different basket. ## GDPR: purpose, choice, and a smaller data footprint [GDPR Article 9](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02016R0679-20160504) concerns, among other special categories, biometric data processed for the purpose of uniquely identifying a natural person; Article 4(14) defines biometric data. Not every audio recording or transcript automatically has that status. Processing speech to recognise a command is not the same purpose as deriving a voiceprint to authenticate a person. Ordinary audio can still be personal data and reveal sensitive information. A voiceprint-based authentication service needs an Article 6 lawful basis and an applicable Article 9 exception where that provision applies. Explicit consent is one possible Article 9 route, not a blanket exemption from GDPR. It must be assessed for validity in the actual setting; a rushed customer with no usable alternative is not a convincing model of freely given choice. Opt-in product design is necessary for this proposal, but is not itself a legal conclusion. Privacy by design begins before enrolment. Explain what is captured, why, who controls it, whether a template is created, retention, recipients, and how to withdraw. Do not bundle authentication consent with advertising, customer profiling, or model training. For the proposed pilot, customer voice and transaction inputs must not be used to train general-purpose models, and merchant engagements must remain isolated. There should be **no ambient customer monitoring**. Capture starts only after deliberate activation, with a visible indication and a bounded listening window. It stops on completion or cancellation. Avoid collecting bystanders and do not create a store-wide voice-identification layer in the background. Raw audio should be processed transiently and deleted promptly after the necessary processing, with a documented maximum retention period and verified deletion—not retained indefinitely “for improvement”. Any exceptional research sample collection needs separate, specific governance and participation choice. Production transaction logs should normally record the necessary outcome and transaction reference rather than the recording. Do not claim that audio never leaves a device unless the measured architecture actually guarantees it. Protected templates need their own retention and deletion rules. Withdrawal or account closure should remove the template when retention is no longer justified, including controlled treatment of backups. A data-protection impact assessment should be considered and completed where the legal criteria require it, alongside controller/processor responsibilities, security testing, and any international-transfer assessment. Architecture diagrams and deletion tests should support the privacy notice; a reassuring paragraph cannot substitute for them. ## AI Act: verification has a boundary, not a blanket exemption The [EU AI Act, Regulation 2024/1689](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02024R1689), distinguishes biometric verification from biometric identification. Annex III, point 1(a), excludes verification whose sole purpose is confirming that a specific person is who they claim to be from that remote-biometric-identification high-risk category. Recital 54 discusses authentication in this context. This is a narrow classification boundary, not an exemption from the entire AI Act, GDPR, or payment law. Searching a customer population without a claimed identity, inferring emotions, or categorising people from their voices changes the purpose and may change the applicable rules. Those functions are outside this proposal. A deployment must assess its actual intended purpose, other relevant obligations, and the Act’s phased application dates; calling a system “authentication” is not enough. ## Inclusion is part of the security specification A voice interface that only works for a confident, enrolment-like speaker in a quiet environment is not a human-centric checkout. Accent, language, illness, ageing, stress, disability, medication, and changes in a person’s voice can affect interaction or verification. Some people cannot speak, cannot hear a readback, do not want to speak a payment instruction publicly, or use assistive communication. A person should not have to disclose a condition to escape a failed voice flow. Provide the same practical ability to pay through a card, wallet, PIN or other provider-supported non-voice route, with clear visual status and accessible controls. Do not impose a voice-only queue, punitive delay, or price difference. Allow cancellation before payment submission and show the definitive payment outcome. Repeated uncertainty should not lock a customer into an enrolment-recovery conversation at the till. Measure command recognition, speaker verification, attack detection, and end-to-end completion separately across relevant conditions and consenting participant groups. Group comparisons require sufficient evidence and careful handling of personal data; small pilot samples cannot prove fairness for a city. Uncertainty should be reported rather than hidden behind an aggregate accuracy figure. ## A Stockholm pilot: gates before scale The following stages are proposed, not completed. The objective is to determine whether an optional voice layer improves a real transaction experience without weakening security, privacy, or access. > **[Locked preview — full framework available in the complete version.](/experience-layer)** ### Pilot scorecard | Dimension | What to measure | Decision evidence | | --- | --- | --- | | Intent and comprehension | Wrong commands, interruptions, correct understanding of merchant and total | Observed behaviour, not transcript accuracy alone | | Verification | False acceptance and rejection at the fixed threshold | Condition-specific results with uncertainty and sample sizes | | Presentation attacks | Replay, synthetic and converted speech acceptance | Held-out attacks and documented gaps in coverage | | Payment integrity | Correct amount, duplicate prevention, authorisation outcome and reconciliation | Provider records matched to the user-visible result | | Usability | Completion time distribution, cancellations, step-up and fallback success | Comparison with the existing checkout; no invented target latency | | Accessibility | Independent completion and usable non-voice alternatives | Participant evidence; explicit limits on representativeness | | Privacy | Capture boundaries, bystander exposure, raw-audio and template deletion | Technical observations and retention audits | | Operations | Staff interventions, recovery, incidents and rollback | Named responsibility and rehearsed stop procedure | > **[Locked preview — full framework available in the complete version.](/experience-layer)** ## The Experience Layer at the point of payment [Europe’s Human-Centric Experience Layer](https://deriss.com/articles/europes-human-centric-experience-layer) asks what infrastructure supports richer real-world participation. Checkout is a concrete test of that thesis: does the interface help a person understand and complete an everyday action, or does it demand another data concession merely to move the queue? [The Next Level: Voice, Identity, and the Game of Life](https://deriss.com/articles/the-next-level-voice-identity-and-the-game-of-life) supplies the broader voice-and-identity context. Payment is the applied boundary where expression must be separated from evidence of identity and consent to a transaction. A natural interaction does not justify opaque authentication. [The Sovereignty Stack and Trust-as-Law](https://deriss.com/articles/the-sovereignty-stack-and-trust-as-law) places trust in demonstrable infrastructure. At a till, the proof is modest and demanding: the intended person, the intended transaction, the right payment controls, minimal retained data, and a working alternative when the voice path fails. The research conclusion is not that shops should recognise everyone by voice. It is that an optional voice layer deserves testing only when it leaves the payment rails intact and makes security, choice, and failure understandable. The strongest human-centric outcome may be a small interface improvement—or the decision not to deploy biometric voice authentication at all. This is a standalone applied report within Experience Layer, not a numbered series instalment. Further essays, frameworks, and reports are available in [Deriss Research](https://deriss.com/research).