Financial Services
Verification that runs on the handset itself, helping carriers protect against SIM swap, support safer activation, and identify fraud signals during sign up
Overview
Verification that runs on the handset itself, helping carriers protect against SIM swap, support safer activation, and identify fraud signals during sign up.
A carrier decides who a customer is when a service is activated, and that decision is trusted every time the phone is used afterwards. Banks, government services and payment apps all lean on it, usually by sending a code to the number and treating whoever receives it as the customer.
That inheritance is the weakness. When a number moves to another device, whether through a swap arranged at a counter or a port that should never have been approved, the trust moves with it, and every service downstream keeps honouring a decision that is no longer true.
The checks below run on the device and confirm the person through their behaviour and appearance rather than relying only on a code that can be redirected, so the account stays attached to the customer rather than to whichever handset currently holds the number.
What you deploy
These are the FaceOff products most often deployed in this sector, in the order they usually land.
Key capabilities
What this sector asks for most often. Each one runs at the moment a decision is being made, and each returns a result a reviewer can explain to somebody else.
Before a connection or a new service is activated, the applicant is confirmed as a live person rather than a photograph, a recording or somebody standing in for them, at the point where the activation can still be refused rather than after it has been used.
A one time code belongs to whichever device currently holds the number. Confidence is held against the customer instead, so a number that has moved to another handset does not automatically carry the account and everything attached to it along with it.
A session that was genuine at sign in can change hands part way through, which is where a plan change, a port request or a beneficiary edit tends to happen. The customer is confirmed quietly while the session is open, so a takeover is caught while it is running.
A payment is approved by confirming that a live, enrolled person is present and willing, so the approval belongs to the customer rather than to a device or a code that can be redirected. It covers the everyday rails customers already use, including UPI, NEFT and RTGS.
Somebody holding a photograph, a screen capture or a video of the customer taken earlier should not be able to present it and be accepted as them. The check is built to resist material captured in advance rather than treating any face in front of the camera as a person.
Impersonating images and video of a person, including the executives and public faces a brand is recognised by, are searched for across online platforms and each match is checked against the real person. The result is kept as a case file that supports a takedown or a complaint rather than a screenshot in somebody's inbox.
Where it is used
Every entry names a product on this site and describes it the way its own page does.
BehaviorBioAuth checks identity from behaviour, continuously, so a session that changes hands part way through is caught.
Facepay confirms a live, enrolled person is at the handset and is willingly approving the payment.
DeepFakeFinder traces suspected deepfakes of a person across online platforms.
Common questions
A one time code follows the number. BehaviorBioAuth checks the person instead and keeps checking through the session, helping identify a takeover after the session has started.
No. The checks run quietly alongside normal use. There is nothing extra for a genuine customer to complete.
Facepay runs its checks on the device, and the payment app receives a decision rather than a face.
At three points: when a service is activated and the applicant is confirmed as a live person, while a session is open and the customer is confirmed quietly in the background, and at the moment a payment is approved. They are the same question asked at the three moments where the answer changes what happens next.
That is the case BehaviorBioAuth is built for. Confirmation does not stop once a session has been opened, so a session that changes hands part way through is surfaced while it is still running rather than reconstructed afterwards from logs.
The checks are designed to confirm a person without that being the result. Facepay runs on the device and returns a decision to the app rather than the face behind it, so protecting the customer does not mean building a new store of biometric material that then has to be defended.
The checks are built to run on the device the customer already has and to hand back a decision rather than the material behind it. What that looks like against your own app, your activation flow and the handsets in your range is worth walking through on a demo rather than answering as a general rule here.
Yes. DeepFakeFinder searches online platforms for impersonating media of a named person, verifies each match against the real person rather than reporting every resemblance, and holds the monitoring as a case file you can take to a platform or a regulator.
Any method of detection can be mistaken in either direction, human judgement included, so a result is an evidence based assessment rather than a guarantee. It is there to focus attention on what deserves a closer look and to be examined and challenged, not accepted without question.
Bring your own footage. We will run it through the Adaptive Cognito Engine and walk you through the findings.
