This is the second of TrustVision's three layers, and it runs on the same capture used in customer onboarding. See how it connects to transaction verification in the full TrustVision overview.
In this piece. Most identity fraud does not look suspicious one application at a time. A real-looking ID, a face that matches it, every field filled in correctly, and the same face may already be on file under other names. This piece explains how TrustVision's fraud prevention layer checks the document itself and compares each new face with the faces already on file, so patterns that are invisible in a single file become visible across a portfolio.
Why this matters under AFASA
Accounts opened under false or borrowed identities are how scam proceeds move. The Anti-Financial Account Scamming Act treats them seriously: under Section 5 of the law, opening a financial account under a fictitious name, or using someone else's identity or identification documents, is an offense in itself, and using or lending an account to move scam proceeds is money muling under Section 4. Enforcement is now visible. The PNP Anti-Cybercrime Group recorded 527 AFASA-related cases in 2025, BusinessMirror reported, and police said they arrested more than 90 money mules between January and April 2026 (BusinessMirror).
For institutions, Section 6 of the law requires adequate risk management systems and controls, naming fraud management systems and account enrollment and verification processes. We covered how mule accounts move money in The Pulse of the Mule. This piece is about catching the identity behind them at the door.
The application that looks fine on its own
A single loan application can be internally consistent: a real-looking ID, a face that matches it, all the fields filled in correctly. And still be fraud, because the same face already opened other accounts under other names, or the ID itself has been altered in ways a human reviewer would not catch by eye.
That is the gap TrustVision's fraud prevention layer is built to close. The question is not "does this application look wrong," but "is there something about this document, or this face, that a clean-looking application would otherwise hide."
Authenticating the ID itself
Three checks make up this layer, run on the same capture used for onboarding:
- Face-to-ID matching. The system compares the customer's live face capture with the photo on the ID and returns a similarity score your team can set thresholds on.
- ID tampering check. The system scans for more than 20 signs of forgery: mismatched fonts, incorrect character spacing, a portrait that has been digitally swapped, a wrong template, and logic errors where the ID number, expiry date, issue date or place of issuance conflict with the document's own rules. Both digital edits and physical alterations, such as a re-laminated card, are covered.
- Government ID validation. Where a government database is available, the ID details are validated against the issuing agency's records, catching forged or synthetic documents that pass a purely visual check.
Together these answer a different question from the identity checks that run first. The question here is not whether a real person is present. It is whether the document and the application in front of you can be trusted.
Beyond the single application: face retrieval
Institutions can build a searchable face database from the KYC images they already hold. Each face is stored as an encrypted mathematical vector, not as a raw image, so a new application can be checked against every face already on file at high speed.
Run across an existing customer base, this is how one face behind several names becomes visible. Each of those applications looked clean on its own. The pattern only shows up across the whole portfolio, which is why onboarding checks alone cannot catch it.
Suspicious Face Alert: fraud intelligence across institutions
The hardest fraud to catch is the kind that moves between institutions. A fraudster who fails at one bank simply tries the next, and without shared intelligence, every institution learns that lesson separately, after the loss.
Suspicious Face Alert is TrustVision's answer: a shared database of face vectors linked to suspected fraudsters and stolen identities, checked in real time through an API during onboarding, so fraud caught at one institution can be flagged before it reaches the next. Institutions take part in one of two ways: as Contributing Members, submitting confirmed fraud cases in exchange for full access to the pooled database, or as Non-Contributing Members, accessing the existing database on a subscription basis without submitting their own data.
Where it fits in the BSP rules
BSP Circular 1213, one of the three circulars that put AFASA into practice, requires covered institutions to run an automated, real-time fraud management system that at minimum looks at transaction velocity, changes to device or account information, geolocation, blacklist screening and behavioural anomalies. Checking new applicants against known fraud faces is one way to apply blacklist screening at the point of onboarding.
The other two circulars cover different ground. Circular 1214 sets the rules for how the BSP inquires into accounts linked to scams and shares that information with authorities, and Circular 1215 covers the temporary holding of disputed funds during a coordinated verification process. Our AFASA compliance checklist sets out all three.
How the data is protected
Face data throughout TrustVision is stored as encrypted vectors, not raw images, and customer data is processed under the Data Privacy Act of 2012 (Republic Act No. 10173). For the Suspicious Face Alert database specifically, the database sits on a private network reachable only by the API server, protected by IP whitelisting and a firewall; personal data is encrypted at rest and can be decrypted only through the API layer; human access is logged and limited to a small set of credentialed staff; and the system is penetration-tested by a third party on a regular basis.
What this layer is, and what it isn't
It is document authentication and cross-institution fraud intelligence: catching tampered IDs, duplicate identities and fraud patterns that span more than one lender.
It is not identity verification. Confirming a real, live person is present and reading their ID correctly happens earlier, in TrustVision's customer onboarding layer. And it is not a credit decision. Whether a legitimate customer should be approved for a loan is a separate question that TrustInsight products like Vision Score are built to answer.
The bottom line
Fraud that looks clean one application at a time is exactly what a face database and a cross-institution alert are built to expose. TrustVision authenticates the document, then checks the face against what every participating institution already knows. See how it works in TrustVision Fraud Prevention.
This article summarises public sources and is not legal advice.
Sources
- Bangko Sentral ng Pilipinas. (2025). Circular No. 1213, Series of 2025. bsp.gov.ph
- Fernandez, B. (2026, April 28). Afasa impact seen with arrest of crooks. BusinessMirror. Link
- Fernandez, B. (2026, September 3). BSP credits Afasa law in gains vs financial fraud. BusinessMirror. Link
- Republic Act No. 12010. (2024). Anti-Financial Account Scamming Act. Lawphil
