A framework for evaluating continuous identity assurance in banking should begin with a precise objective: maintaining greater confidence in the authorised user’s identity after login, particularly when higher-risk actions take place.
A framework for evaluating continuous identity assurance in banking must also recognise the boundaries of that objective. Identity assurance does not replace authentication, detect every compromised device, determine whether a transaction is safe or establish whether a customer has been manipulated.
1. Define the identity problem
The first step is to identify the question the organisation expects continuous identity assurance to answer.
A suitable objective may be:
“Can we maintain greater confidence that the authorised customer remains the person interacting with the application when a higher-risk action is completed?”
This is different from asking:
- Is the device free from malware?
- Does the transaction match the customer’s usual behaviour?
- Is the payment destination trustworthy?
- Has the customer been deceived?
- Should the transaction be approved?
Those questions remain important, but they belong to other parts of the security and fraud-control environment.
2. Map the higher-risk actions
Evaluation should focus on specific in-app actions rather than the entire application in the abstract.
Relevant banking and financial-services examples may include:
- Adding a beneficiary
- Approving a high-value payment
- Increasing a transaction limit
- Linking an external wallet
- Changing a payout account
- Authorising another device
- Replacing contact details
- Redirecting transaction notifications
For each action, assess the potential financial consequence, the effect on account control and the difficulty of reversing it.
3. Map the existing controls
Continuous identity assurance should be evaluated in relation to the controls already in place.
- Password or PIN: Was the expected secret entered?
- One-time PIN: Is the receiving channel accessible?
- Device recognition: Is the application operating on a recognised device?
- Biometric verification: Was the authorised person present when the check occurred?
- Transaction monitoring: Does the action appear unusual or higher risk?
- Continuous identity assurance: Does identity confidence extend beyond the initial check?
This comparison helps prevent overlapping technologies from being treated as interchangeable.
4. Test realistic fraud scenarios
A useful evaluation should include more than a successful customer journey.
Scenarios may include:
- Stolen credentials used from an expected device
- A one-time PIN intercepted after a SIM swap
- A session operated remotely through a compromised device
- Another person taking control after the customer has logged in
- A legitimate customer being manipulated into making a payment
The final scenario is particularly important. Continuous identity assurance may confirm that the authorised customer is present, but it does not establish whether that customer is acting under deception or coercion.
This limitation should form part of the evaluation rather than being treated as an exception after implementation.
5. Examine the relationship between identity and transaction risk
Identity and transaction risk are related, but they are not identical.
An organisation may have strong confidence in the user’s identity and still identify a payment as unusual. It may also encounter a transaction that appears normal even though someone else is directing the session.
Evaluation should therefore consider how identity information contributes to the broader decision without assuming that identity alone determines whether an action should proceed.
6. Assess the technical and operational evidence
Providers should be able to explain how the technology operates within the proposed application environment and what the customer must implement around it.
Evaluation questions should include:
- At which points in the application is identity assurance available?
- What information or event does the technology provide?
- How can the organisation respond when identity confidence changes?
- Which components operate on the device and which rely on other infrastructure?
- What personal information is processed?
- How is that information stored, retained and protected?
- What evidence supports accuracy, liveness and spoof-resistance claims?
- How does the technology affect application performance and customer experience?
- Which responsibilities belong to the provider and which remain with the customer?
Answers should be supported by current technical, privacy and contractual documentation rather than broad marketing claims.
7. Establish governance before deployment
Technology evaluation should include the people and processes responsible for its use.
Banks should define:
- Which teams own the control
- Which actions require additional identity confidence
- What happens when confidence cannot be maintained
- How exceptions and customer disputes are handled
- What evidence is retained
- How the control is tested and reviewed
- How privacy and customer communication requirements are addressed
These decisions determine how identity assurance functions within the wider fraud and risk environment.
8. Evaluate customer impact
An effective control must support security without adding unnecessary friction to low-risk interactions.
The evaluation should consider:
- Whether the control is proportionate to the action
- Whether customers understand what is expected
- Whether accessibility requirements are addressed
- Whether legitimate customers have an appropriate alternative route
- Whether support teams can explain and resolve problems
- Whether the organisation can measure both security value and customer impact
The objective is not to add another visible check everywhere. It is to strengthen identity confidence where the consequence justifies it.
Where Datanamix fits
Datanamix provides Continuous Facial Recognition with Liveness as part of its identity and verification technology portfolio.
The solution is designed to help banks, fintechs and other financial-services organisations extend identity assurance beyond login while complementing their existing authentication, device and transaction controls.
Datanamix can help organisations examine where additional identity assurance may fit within higher-risk in-app journeys without positioning it as a replacement for the controls already in use.
Book a demo with Datanamix to discuss the technical, operational and governance questions relevant to your environment.
