This is the third of TrustVision's three layers, and it depends on the face registered during customer onboarding. See how it connects to fraud prevention in the full TrustVision overview.
In this piece. An OTP proves someone has the phone. It does not prove that person is your customer. With the BSP now expecting stronger authentication than SMS codes for high-risk transactions, the question for most institutions is no longer whether to move to face authentication, but how to move millions of existing customers onto it. This piece covers how it works, where it fits, and a phased rollout plan.
An SMS code proves possession: whoever received it has the phone, the SIM, or access to whatever intercepted it. It was never designed to prove identity, and SIM-swap fraud, phishing and OTP interception exploit exactly that gap. In authentication terms, an OTP is a possession factor, something you can lose, lend or have stolen. A face is an inherence factor, something you are, which is far harder to hand over. We wrote about what that means for customers in The End of the OTP.
The rules now reflect this. BSP Circular 1213 tells institutions to limit authentication that can be shared with or intercepted by third parties, names SMS and email OTPs as examples, and lists stronger alternatives including biometric authentication. Its one-year transition ended on June 25, 2026. The BSP has said lower-risk transactions may still use SMS OTPs, while high-risk ones need the stronger methods (BusinessWorld). And under Section 6 of AFASA, an institution that fails to put adequate controls in place is liable to restore a scam victim's funds, with no criminal conviction needed first. Our AFASA compliance checklist covers the full set of requirements.
The system runs in two stages. First, face registration: during onboarding, or using the face photo from an existing KYC record, the system extracts biometric measurements from the customer's face and stores them as a template in a central biometric database. Second, face authentication: at the moment of a transaction, the system captures the customer's face again, runs a liveness check to confirm a real person is present, and compares the capture against the registered face. A failed liveness check stops the process before matching happens; a face that does not match fails authentication outright.
In March 2026 the BSP released an exposure draft that would recognise server-side biometric authentication, where a customer's face or fingerprint is checked against a template the institution holds rather than only on the phone, as a strong and acceptable control for high-risk transactions and critical account changes. That is the registration-and-match model described above.
The draft also lists the safeguards it expects: encrypted templates instead of raw images, liveness and deepfake detection, human review of flagged cases, equally strong fallback methods, monitoring of false acceptance, false rejection and performance across customer groups, and designs that work for elderly users, people with disabilities and customers on lower-end phones (see also BusinessWorld's coverage). As of October 2026 it had not been issued as a final rule, so check bsp.gov.ph for its current status before you build to it.
Face authentication can replace or supplement existing verification across the channels a bank customer touches:
Fraudsters attack face authentication in two ways: presentation attacks, showing an artificial face to the camera through a photo, video or mask, and injection attacks, tampering with the camera feed itself to substitute a deepfake before it reaches the system. TrustVision's liveness detection, certified to ISO/IEC 30107, runs before any face comparison to stop both.
In one case from a TrustVision deployment, a fraudster repeatedly tried to authorise transactions on a customer's account using a video of the account holder's face. Every attempt failed the liveness check. When the fraudster finally showed his own face to the camera, it failed the face match. The account was never compromised.
The hardest part of face authentication is rarely the technology. It is asking millions of existing customers to register a face they never had to provide before. TrustVision's approach is a phased, risk-based rollout rather than a single cutover: trigger face registration at digital moments customers already pass through, position it as a feature rather than a mandate, use branch and assisted channels to re-verify customers who are not yet digital-first, and keep participation voluntary but worth taking up.
A typical phased timeline runs 90 to 180 days:
No institution has to switch its entire base over at once, and the BSP still allows OTPs for lower-risk activity while the rollout runs.
99% of face-compare requests are served in under 550 milliseconds, and the system has held a peak of 96 transactions per second at 100% success in production. That matters here, because transaction authentication has to run at the speed of a login or a transfer, not the more forgiving pace of a one-time onboarding.
It is transaction and login authentication: proving the person behind an action is who they claim to be, using a face instead of a code sent to a device.
It is not identity verification for new applicants, which happens earlier in TrustVision's customer onboarding layer. And it is not document fraud detection: catching a tampered ID or a duplicate identity is handled by TrustVision's fraud prevention layer. This layer answers a narrower, ongoing question: for this specific action, right now, is this really the account holder?
An OTP was always a proxy for identity, not identity itself. TrustVision authenticates the person directly, at the moment that matters, and is built to get an existing customer base there in phases rather than all at once. See how it works in TrustVision Transaction Verification.
This article summarises public sources and is not legal advice.