{"id":9536,"date":"2026-08-31T11:06:57","date_gmt":"2026-08-31T09:06:57","guid":{"rendered":"https:\/\/datanamixdev.wpengine.com\/media\/?p=9536"},"modified":"2026-08-31T11:06:57","modified_gmt":"2026-08-31T09:06:57","slug":"when-should-banks-apply-additional-identity-assurance","status":"publish","type":"post","link":"https:\/\/www.datanamix.com\/media\/2026\/08\/31\/when-should-banks-apply-additional-identity-assurance\/","title":{"rendered":"When should banks apply additional identity assurance?"},"content":{"rendered":"

When should banks apply additional identity assurance? Banks should consider it when an in-app action can move money, change account control, redirect future payments or make subsequent fraud more difficult to identify.<\/p>\n

The question \u201cWhen should banks apply additional identity assurance?\u201d is best answered according to consequence rather than convenience. Viewing an account balance does not carry the same risk as adding a beneficiary, increasing a payment limit or authorising a new device.<\/p>\n

Does every in-app action need the same identity check?<\/h2>\n

No. Applying the same level of identity assurance to every interaction may introduce unnecessary friction without reflecting the actual risk.<\/p>\n

A customer checking a balance or reviewing a recent payment is not making the same type of decision as someone changing payout details or releasing funds.<\/p>\n

A more practical approach is to identify the points where an action can materially affect the customer or the organisation. These are the moments where greater confidence in the person behind the screen may add the most value.<\/p>\n

Which actions may require greater identity confidence?<\/h2>\n

Banks and financial-services organisations can begin by reviewing actions that affect:<\/p>\n

Movement of money<\/h3>\n

Examples include approving a high-value payment, drawing down available credit or transferring funds to a newly added beneficiary.<\/p>\n

Control of the account<\/h3>\n

Changing contact details, resetting security settings or authorising another device can influence who receives alerts and who can access the account later.<\/p>\n

Payment destinations<\/h3>\n

Adding a beneficiary, linking an external wallet or replacing a payout account creates a new destination for funds.<\/p>\n

Recovery and detection<\/h3>\n

Redirecting transaction notifications or changing registered contact details can make unusual activity more difficult for the customer to notice quickly.<\/p>\n

The right list will depend on the institution\u2019s products, customer journeys and existing controls.<\/p>\n

Is another one-time PIN enough?<\/h2>\n

A one-time PIN can provide a useful additional check, but it confirms access to the channel receiving the code. It does not always establish who is operating the application.<\/p>\n

This becomes particularly relevant when a phone, SIM or email account has been compromised. The expected code may still be entered even though another person controls the session.<\/p>\n

The practical question is therefore not whether one-time PINs have value. It is whether possession of the receiving channel provides enough confidence for the action being completed.<\/p>\n

How is identity assurance different from transaction monitoring?<\/h2>\n

Identity assurance and transaction monitoring address different parts of the risk.<\/p>\n

Identity assurance focuses on the person interacting with the application. Transaction monitoring assesses the action itself, including whether it differs from expected behaviour or meets a higher-risk threshold.<\/p>\n

A payment may appear unusual even when the authorised customer is present. Alternatively, a payment may appear consistent with previous activity even though someone else is operating the account.<\/p>\n

Using these controls together can provide a broader view than relying on either one alone.<\/p>\n

What if the legitimate customer is being manipulated?<\/h2>\n

Additional identity assurance cannot establish whether an authorised customer has been deceived or pressured into making a payment.<\/p>\n

If the customer remains present and completes the action personally, an identity check may confirm the correct person without identifying the manipulation behind the transaction.<\/p>\n

Banks still need customer education, payment controls, behavioural analysis and fraud-response processes for social-engineering scenarios involving legitimate customers.<\/p>\n

Where does Continuous Facial Recognition with Liveness fit?<\/h2>\n

Continuous Facial Recognition with Liveness is designed to strengthen existing authentication by extending identity assurance throughout an active digital session.<\/p>\n

It can provide additional identity confidence around higher-risk actions without replacing passwords, one-time PINs, device recognition, transaction monitoring or other fraud controls.<\/p>\n

Its specific role is to help the organisation maintain greater confidence that the authorised user remains the person interacting with the application.<\/p>\n

How should banks decide where to begin?<\/h2>\n

A practical starting point is to map the actions available after login and group them according to consequence.<\/p>\n

Teams can ask:<\/p>\n