Last week I headed to Charlotte NC for Datos Insights’ Financial Crime and Cybersecurity Forum.
It was a great event, and I got to spend a lot of time talking with people at banks and other financial institutions about what they’re working on right now.
A lot of those conversations centered on the same themes.
Here are the five I came away thinking about most.
One topic that kept coming up was how to carry trust across channels.
Customers interact with their bank in a lot of different ways: the mobile app, the web, contact centers, physical branches, and increasingly through AI-driven experiences.
In many cases, the bank has already spent years establishing trust with the customer's mobile device. Why throw that trust away just because the next interaction starts in another channel?
So we’ve been thinking a lot about how that trust can be useful when the customer shows up somewhere else.
Say I walk into a branch and ask to make a sensitive change to my account. If I have my trusted device with me, that gives the bank another way to verify that it’s really me.
Or say I call the contact center. Instead of authenticating me based only on PII or questions that someone else may know the answers to (KBA), the bank can also use my trusted mobile device as part of that verification.
The broader opportunity is to carry established trust from the mobile app into the rest of the bank.
The same idea applies when an interaction starts on the web, or when an AI agent initiates an action on my behalf. With cross-device authentication, we can connect that interaction back to a trusted mobile device and use physical-world context as part of the authentication decision.
More banks are starting to migrate to passkeys.
I think that’s a good thing. Passkeys are phishing resistant, they improve the user experience, and I expect them to become the standard.
The part I keep coming back to is recovery.
At some point, a customer is going to replace a phone, lose it, or need to register a passkey on a new device.
The bank still has to verify that the new device belongs to the legitimate account holder.
A lot of implementations fall back to a password or OTP for that step.
The problem is that if a fraudster can compromise the recovery process, they can register a new passkey without ever attacking the passkey itself. The passkey can remain phishing-resistant while the account itself is only as resilient as the recovery process around it.
So recovery needs to be designed with the same care as the login experience.
This is where additional identity signals can help.
Across the banking traffic we analyze, more than 90% of legitimate new-device activity happens from a trusted location, like the customer’s home or workplace.
That gives the bank more context when someone shows up on a new device.
A new phone appearing at a place the customer visits regularly is a very different situation from one appearing somewhere completely unrelated to their history.
As banks adopt passkeys, I think the recovery flow is going to matter just as much as the passkey itself.
Agentic AI was probably the topic I heard about most.
It isn’t a major source of fraud volume yet, but what struck me was how many banks are already thinking about the controls they’ll need as agents begin taking more consequential actions.
Knowing that the request came from a legitimate agent gives you one piece of the picture.
You still have to decide whether the action itself makes sense.
If my AI agent wants to book a hotel or reorder something I buy every month, that may be relatively low risk.
If it wants to move money, change account information, or do something more sensitive, I may want the bank to check with me first.
We’ve been working on ways to connect those higher-risk agentic actions back to the customer’s trusted mobile device.
The agent can initiate the action, and the bank can bring the customer back into the flow when it needs more confidence.
I also think physical-world signals are going to matter here.
AI agents can imitate a lot of digital behavior, but they don’t have the same physical-world history as the person they’re acting for.
I joined a roundtable on scam detection.
A lot of that conversation came back to mule accounts.
With APP scams, for example, we spend a lot of time looking at the victim sending the money.
In many of the APP scam cases we analyze, the receiving side ultimately depends on mule accounts.
The challenge is that mule accounts can be very difficult to identify. Many belong to real people who legitimately passed KYC and behaved normally for months before the account was ever used for fraud.
An individual account can look legitimate. The network around the account often tells a different story. That means you need enough context to recognize when the behavior of that account changes or when it starts showing connections to other suspicious activity.
Those connections can give the receiving institution a much clearer picture of what’s happening and help identify mule activity earlier.
I wrote more about the quality of the signals needed to detect mule accounts here.
OTPs have been around forever, and banks are still trying to figure out when they actually need them.
I kept hearing versions of the same questions: When can we avoid an OTP? How much can we reduce our reliance on it?
Every time you ask the customer to complete another authentication step, you add friction.
So the question becomes, how confident are we that this is really the customer before we ask them to verify again?
If I’m on a device the bank has known for a long time, in a context that looks consistent with my normal behavior, that should count for something. Across Incognia’s banking traffic, we see that 70-80% of the sessions occur from trusted locations such as the user’s home and workplace.
If I’m on a new device, far from my trusted locations, and trying to do something higher risk, then asking for additional verification makes more sense.
This is where continuous identity becomes useful.
The more the bank understands about the customer and their trusted locations over time, the easier it is to decide when an OTP is actually necessary.
What stayed with me after these conversations is how many different places banks now have to make a trust decision.
A customer might be logging in from a familiar device, calling the contact center, walking into a branch, recovering access on a new device, or eventually asking an AI agent to act on their behalf.
The channel keeps changing. The underlying question is: how much confidence do you have that the person behind the interaction is really your customer?
That’s why I keep coming back to continuity.
Banks have traditionally authenticated individual moments. Increasingly, they need enough context over time to recognize the customer even when the device, channel, credential, or interface changes.
The more continuity a financial institution has, the better it can distinguish what looks normal from what deserves more scrutiny, and decide when additional verification is actually necessary.
I’ll probably go deeper on a few of these topics in future editions. If there’s one you’d like me to dig into, reply and let me know.