This is the next post in our series on how real customers use the Zumigo platform to solve real problems: a global bank, spanning both everyday banking and investment product lines, that runs two different real-time checks depending on one thing — whether the person in front of it is opening a relationship or continuing one.
Every account starts with a moment this customer treats as its own category of risk: someone applying who may not be who their information says they are. Every account is also used, afterward, millions of times over, by someone who already passed that test once and now just needs to get back in. Those are different questions, and this customer’s usage data shows it treating them that way — not with one blanket stack of checks run everywhere, but with two distinct sets, applied at exactly the moment each one answers something real.
When someone applies for a new account, the risk isn’t primarily that a fraudster is impersonating an existing customer — it’s that the identity itself may not exist as a real, coherent person at all. Synthetic identity, built by combining various real PII elements into a person who doesn’t actually exist, is designed to pass a cursory check on each individual element while failing one that looks at the whole picture. So at this moment, this customer validates the applicant’s name and address directly, live.
Alongside that, because the bank still needs to reach this brand-new customer to verify they possess the phone number on the application, it checks the integrity of that channel before trusting a one-time code sent to it: has the SIM changed recently, has the device changed recently, and is call forwarding active on the line. A code is worthless as proof of possession if the line carrying it has quietly been redirected. Identity and possession, checked together, at the one moment both are still fully in question.
Every time an existing customer signs back in, this customer runs the same three checks on the phone and line, minus the identity validation. That isn’t an oversight — by sign-in, the bank already knows who this customer is supposed to be, so re-running a name-and-address check would be answering a question that isn’t in doubt. What is in doubt at sign-in: has anything changed about the phone or the line since this customer was last legitimately verified — the exact profile of an account takeover in progress.
Running every check everywhere would be simpler to build. This customer’s usage data shows the opposite discipline: identity validation appears only where identity itself is the open question, and disappears once that question is answered. What stays constant is that the phone and line get checked live, immediately before a code is trusted or a session is granted — because a SIM change, a device change, or forwarding turned on an hour ago is exactly as dangerous as one turned on a minute ago, and only a check run right now catches both.
There’s a broader point here that goes beyond this one bank. Identity fraud defense actually gets easier, not harder, once the phone becomes the main way a customer reaches a business, because a phone carries a live, checkable trail — SIM state, device state, how its calls are being handled — that a password or a static identity record never could. The more of a relationship that runs through the phone, the more real-time signals there are to bring to bear on it.
Worth noting separately: this customer’s checks all run against the phone directly, but that isn’t required for the protections to apply. Zumigo can delegate that same trust to a desktop or tablet session — the customer scans a QR code with their phone, and the real-time signals read from that phone carry the assurance back to the screen they’re actually using. This bank doesn’t use that pattern today, but the same checks aren’t limited to phone-native interactions; they extend to wherever the customer’s phone happens to be.
This also runs at some of the highest sustained volume we see from any single relationship on the platform, spanning banking and investment lines alike — the kind of scale that shows up when a security architecture is built into how a bank operates, not bolted onto one part of it.
Madhu Vudali is VP, Product Management at Zumigo. Comments or questions? Connect on LinkedIn: @madhuvudali