Bank of Thailand Proposes Stricter Facial Recognition Standards for Financial Services
Introduction
On 14 September 2026, the Bank of Thailand (“BOT”) released for public consultation a set of draft guidelines on the use of facial recognition technology for identity verification (the “Draft Guidelines”). These Draft Guidelines are designed to ensure that facial recognition systems used for financial transactions are secure and reliable. The consultation period closes on 13 October 2026.
Facial recognition has become the primary biometric method used by Thai financial institutions, particularly in mobile applications for account opening, fund transfers, and service registration. While this technology offers convenience and security, the BOT has highlighted a growing concern threat: attacks using AI-generated “deepfakes” are increasing in frequency and sophistication. Such attacks can enable unauthorized transactions, resulting in fraud, harm to customers, and diminished confidence in digital financial services.
The Draft Guidelines would set a higher security standard for facial recognition across all BOT-supervised institutions. Once finalized, these Draft Guidelines will replace the existing guidelines issued in September 2023.
Key Provisions of the Draft Guidelines
1) Scope of Application and Key Definitions
The Draft Guidelines apply to all BOT-supervised institutions that use facial recognition in mobile applications: (i) financial institutions and (ii) specialized financial institutions, both under the Financial Institutions Business Act; (iii) payment service providers under the Payment Systems Act; and (iv) supervised personal loan businesses and (v) supervised nano-finance businesses, both under Ministry of Finance notifications issued pursuant to Clause 5 of Revolutionary Council Announcement No. 58. The term “service users” covers both individuals and juristic persons.
The Draft Guidelines introduce the concept of an “identity verification service provider,” defined as a third party engaged to operate or take responsibility for the facial recognition verification process, such as an Identity Provider (IdP) or Electronic Know Your Customer (eKYC) Provider. The Draft Guidelines also classify presentation attack instruments (PAIs) by level of complexity: low (which a layperson can prepare within one day using readily available media such as social media photos or videos), medium (requiring specialist knowledge or skill, up to one week of preparation, or media that are moderately difficult to access), and high (requiring expert-level skill, more than one week of preparation, and detailed facial media suitable for producing realistic masks or three-dimensional models).
2) End-to-End Security
The Draft Guidelines require security measures across every stage of the facial recognition process: image capture, processing, data storage, face comparison, and the final verification decision. Notably, the BOT has adopted an outcome-based approach: the draft specify the outcomes that providers must achieve, while allowing some flexibility in how those outcomes are met.
3) System Security
Facial recognition systems must be placed in secure network zones. Security patches must be applied promptly through a risk-based process. Where patches are unavailable, compensating controls must be implemented, and where installation is not possible, formal approval for an exception must be obtained.
Vulnerability assessments must be conducted at least quarterly and upon any significant change, such as a change of technology, technology provider or identity verification service provider, an update to an algorithm or model, or an adjustment to thresholds. Results must be reported to those responsible and remediation tracked, with progress presented to the board of directors or designated executives. Penetration tests must be conducted at least annually and upon any significant change, covering, at a minimum, presentation attacks, video injection attacks, and API attacks. Importantly, those conducting penetration tests using presentation attacks must be independent of those carrying out presentation attack detection (“PAD”) performance testing.
Providers must keep logs sufficient to support audits, incident investigations, and use as legal evidence. Logs must cover, at a minimum: access to and creation, modification, and deletion of biometric data; enrollment events; successful and failed verification or authentication attempts; changes to access rights; and changes to settings that may affect performance. Logs must be protected against unauthorized alteration or destruction and retained for at least 90 days, or longer if required by law.
4) Image Capture Requirements
Applications must detect rooted or jailbroken devices and emulated environments (including virtual devices, emulators, and simulators), and must reject facial recognition verification when either is detected. Applications must incorporate anti-reverse-engineering measures, including, at a minimum, code obfuscation. They must detect tampering or interference using mechanisms such as anti-tampering, anti-hooking, anti-debugging, runtime integrity checks, and SDK integrity checks, and must reject the verification if either is detected. Captured facial data must not be retained on the customer’s device after verification.
Providers must give customers clear guidance on image capture conditions, including adequate lighting, removing face coverings, positioning the face within the frame, and following movement prompts. Where customers are required to remove glasses, providers must ensure they can still follow the instructions, for example through text or symbols that are clearly visible without glasses, or through voice guidance. Providers must set image quality criteria (covering factors such as resolution, sharpness, face size, and absence of other faces), check each image against the criteria before use, and reject any image that does not meet them. PAD is mandatory, and verification must be rejected whenever a presentation attack is detected. For high-risk transactions, providers may consider randomized active liveness detection, such as asking service users to move their head in response to random prompts, or projecting light or color flashes onto the face in a random sequence. Providers must have mechanisms to prevent replay attacks, such as a challenge-response process using a nonce or other one-time value, and must limit how long each request remains valid.
5) Data Processing and Storage
Facial data, biometric references, and other personal data must be stored separately, at least through logical separation (such as separate databases or tables), and access rights to each must also be set separately. Directly identifying data such as names, national ID numbers, passport numbers, or customer numbers must not be used as file names or linking keys; providers may instead use keys generated specifically for this purpose, such as random values. Where a provider engages a third party for facial recognition services (e.g., an IdP or a SaaS provider), it must ensure that the third party does not retain customers’ facial data unless retention is required by law.
Access to biometric data and to any settings that may affect performance (such as comparison thresholds) requires multi-factor authentication. The principle of least privilege must be applied, access rights must be reviewed regularly and whenever a user’s role changes, and a formal exception process with a risk assessment is required where multi-factor authentication is not technically supported. Biometric data must be encrypted and its integrity verified both at rest and in transit, using algorithms, key lengths, and channels consistent with international standards. Key management must cover the full lifecycle: generation, storage, distribution, rotation, revocation, and destruction. Providers must also have a process to revoke and re-enroll biometric references when they are compromised or suspected of being compromised, and when a specified period or condition is reached (for example, when a customer renews their national ID card). The customer's identity must be securely verified before re-enrollment.
6) Comparison and Decision
Comparison scores must be disclosed only where strictly necessary. The number of consecutive failed attempts must be limited in accordance with international standards. The Draft Guidelines give an example based on NIST SP 800-63B: after 10 consecutive failures, a delay of at least 30 seconds is imposed before the next attempts, and after 100 consecutive failures, facial recognition is suspended and an alternative verification or authentication method is offered.
7) Performance Standards
The Draft Guidelines set specific quantitative performance benchmarks. The false match rate (“FMR”) must not exceed 0.01%, consistent with NIST SP 800-63B. The impostor attack presentation accept rate (“IAPAR”) must not exceed 4% for each attack instrument species. Face comparison and PAD performance must be tested in accordance with the testing frameworks in Appendix A and Appendix B, respectively, at least annually and upon any significant change. As with penetration testing, PAD performance testers must be independent of those conducting penetration tests using presentation attacks.
Providers must establish monitoring processes to detect performance degradation and must respond promptly to emerging threats or vulnerabilities.
8) Testing Frameworks
Appendix A of the Draft Guidelines govern face comparison testing. Tests must use production-equivalent settings (including the face comparison threshold), and these must remain unchanged throughout testing. The minimum number of test transactions is 300,000 for a 0.01% target FMR, calculated using the formula 30 ÷ target FMR. A minimum of 776 test subjects is required. Test subjects should reflect the actual or target user base; for example, where most users are Thai, at least 80% of subjects should be Thai. Subjects should also be appropriately spread by gender and age. The Draft Guidelines’ examples, based on ISO/IEC 19795-5, are that men and women should each make up 40–60% of subjects, and each of the three age bands (18–30, 31–50, and 51–70) should make up 25–40% of subjects, in accordance with ISO/IEC 19795-5. Image types must match real-world use (for example, if live operation compares a selfie with a national ID card chip photo, the test must do the same and not use a previously stored selfie instead). Separate test sets are required for each combination of settings and reference image type.
Appendix B of the Draft Guidelines govern PAD testing. Tests must be conducted end-to-end on the facial recognition system with PAD enabled, not on the PAD subsystem alone. The number of test subjects must be sufficient and in line with international standards, such as at least 15 subjects under FIDO Biometrics Requirements v4.0. The same demographic guidance also applies. Testing should cover a sufficient range of PAI species, such as at least 6 low-complexity and 8 medium-complexity attack instrument species. The tests must include, at a minimum, two specific species: a deepfake video and a live-stream video of a face, each displayed on a QD-OLED monitor with a resolution of at least 3,840 × 2,160 pixels and a glare-free finish (or an equivalent display). For each species, a separate attack instrument must be made from each test subject, and each attack instrument should be used in a sufficient number of test transactions, such as at least 10. With 15 subjects, this means at least 150 transactions per species. One operating system must be used per test set, and separate test sets are required for each combination of settings and operating system. Examples of attack instruments include low complexity (printed social media photos, photos or videos displayed on screens, deepfake video generated from a single image), medium complexity (videos following liveness prompts, paper masks made from high-resolution photos, deepfakes generated from multiple images or video), and high complexity (ceramic, silicone, or theatrical masks; 3D-printed faces or realistic face models).
9) Reporting and Consultation
Clause 5 of the Draft Guidelines set out a tiered reporting and consultation framework. Providers already using facial recognition and PAD must, within 90 days from the day after the Draft Guidelines are issued in final form, conduct face comparison testing, PAD testing, and a compliance assessment, and report the results to the BOT. Prior test or assessment results may be used if they are no more than one year old as of the issuance date and meet the new requirements; any gaps must be filled by additional testing before the results are reported. In subsequent years, tests must be conducted at least annually but need not be reported unless the BOT requires reporting or additional testing on a case-by-case basis (for example, when new attack types emerge). Providers currently submitting reports on their use of biometric technology in the legacy format must stop doing so from the day after the Draft Guidelines are issued in final form.
Where a provider adopts facial recognition for the first time or changes its technology, technology provider, or identity verification service provider, face comparison testing, PAD testing, and a compliance assessment are required. Where the adoption or change concerns only PAD technology or PAD providers, face comparison testing is required only if face comparison performance is affected. Other significant changes to the facial recognition system or PAD require corresponding performance tests. The Draft Guidelines do not require a compliance assessment for these “other” significant changes.
Providers must consult the BOT before using other biometric modalities (such as iris or fingerprint recognition) or using facial recognition for purposes other than identity verification or authentication. The Draft Guidelines attach three reporting forms: Form 1 (face comparison test results), Form 2 (PAD test results), and Form 3 (compliance assessment results, with the assessment to be carried out by internal audit or an independent external auditor). Test results from technology developers, technology providers, or identity verification service providers may be used if they are no more than one year old and consistent with the framework.
Timeline and Practical Impact
The comment period closes on 13 October 2026. Once the Draft Guidelines are finalized, the 90-day compliance window will begin. Given the scope of the requirements, providers are advised to conduct a gap assessment now rather than wait for the final version.
The practical impact is likely to be significant across the financial sector. Banks, payment service providers, personal loan operators, and nano-finance businesses will need to review and likely upgrade their mobile application security, PAD capabilities, biometric data architecture, access controls, and logging infrastructure. The testing requirements are substantial: for each system configuration, at least 300,000 test transactions, 776 test subjects, and multiple attack scenarios.
Third-party eKYC and identity verification vendors are likely to face flow-down requirements, including prohibitions on retaining customers’ facial data (unless required by law) and obligations to provide testing evidence and support audits. Existing vendor agreements may require renegotiation.
From a governance perspective, remediation progress must be reported to the board of directors or designated executives. The requirements for different categories of testers to be independent of each other will call for careful planning of internal resources or the engagement of external specialists.
Conclusion
The Draft Guidelines represent a significant step forward in the BOT’s biometric security framework, moving from principles-based guidance to more prescriptive, measurable, standards-based requirements. By anchoring its performance requirements and testing methods to international benchmarks, including NIST SP 800-63B, ISO/IEC 19795-5, ISO/IEC 30107, and FIDO Biometrics Requirements v4.0, the BOT aims to strengthen the financial sector’s defenses against deepfake and presentation attack fraud while maintaining public confidence in digital financial services.
