The FRONT Framework: Improving Account Opening Decisions Before Fraud Occurs

Imagine your organization uncovered a major fraud loss. Your team traces the transactions, rebuilds the timeline and assesses how the fraudster got through. As investigators work backward, they discover that key warning signs were there from the very beginning. The account holder’s identity didn't quite hold together. The phone number had only recently been created. The same device had shown up on multiple applications. However, none of that proved fraud on its own, so the account opening application went through.

Working in fraud strategy and analytics over the years, I started noticing the same pattern repeatedly. By the time the first suspicious transaction showed up, the account had already passed several chances for someone to ask a better question. Fraud prevention shouldn't start with that first suspicious transaction; it should start the moment someone asks to become a customer.

Whether you're opening a checking account, issuing a credit card, onboarding a business customer or setting up an account on a fintech platform, account opening is the front door for fraudsters.

Every fraudulent account that slips through controls creates the risk of losses, customer harm, costly investigations and regulatory scrutiny. In many cases, those consequences can be traced back to an application that warranted a closer look.

Recognizing Early Warning Signs

Today's fraudsters rarely rely on one trick. They combine stolen identities, fabricated details, compromised devices and convincing information to create an application that appears to look legitimate. On their own, any single piece may seem perfectly reasonable to begin processing a new application.

One lesson has stood out to me over the years: Trust the relationship between the data points, not the data points themselves. Fraud isn’t usually revealed by a single inconsistency. It hides in the details nobody thought to compare and in the questions that nobody thought to ask. Learning to listen beyond what sits on the surface of the application is what separates a good fraud examiner from a great one.

The goal is not finding one perfect red flag, but rather, figuring out whether the whole story is sound. No matter the product or the channel, I keep coming back to these five questions.

1. Can you trust where the application came from?

• Before verifying who someone is, look at where the application is actually coming from.
• Does the IP address match their reported residence?
• Is the connection running through a VPN or another anonymizing service?
• Has the device appeared on other applications recently, perhaps under different names?
• Are several applications coming from the same device in a short window?

None of these instances automatically confirm fraud. Plenty of legitimate customers travel frequently or use VPNs and public Wi-Fi. What matters is whether the device, the location and the application all tell a cohesive story.

2. Can you trust the identity?

• Checking that an ID exists isn't the same as verifying an identity. The real question is whether the data all points to the same person.
• Does the name match the date of birth?
• Is the Social Security number tied to more than one identity or to someone who is deceased?
• Is the mailing address a legitimate residency? Does it map to a P.O. Box, correctional facility or another location that may not establish where the applicant lives? These addresses may not be fraudulent, but they signal weaker evidence of residency and may make it easier for someone to receive account materials without revealing their true location.
• For business accounts, does the Employer Identification Number (EIN) match the registered company?

Fraudsters are good at mixing real information with fabricated details. Legitimate identities tend to be internally consistent. Fraudulent ones often fall apart once you start connecting the pieces.

3. Can you trust the contact information?

• A phone number or email says a lot about intent.
• Does the phone number belong to the applicant?
• How long has the phone number or email address been active?
• Does the email look like something a real person would choose, or a random string of characters from an untrusted domain?
• Has any of the contact information appeared on a fraud list before, internally or externally?

A brand-new phone number isn't unusual by itself. People switch carriers or get new numbers all the time. Combine it with a recently created email, a new device or an unfamiliar identity, and now the picture begins to change.

4. Does the applicant behavior make sense?

• Are several applications arriving within minutes of each other?
• Is the same device tied to different identities?
• Are unrelated applicants sharing a phone number or address?
• Has this person had an unusual number of recent credit inquiries elsewhere?

Some fraud only becomes visible once you stop looking at one application and start looking across many. I've seen applications that looked perfectly reasonable in isolation. It was only after comparing them with a handful of others that the pattern became obvious. The strongest signal is often less about one application and more about how several applications relate to each other.

5. What data do you already have access to?

One of the strongest fraud tools isn't something you buy. It's what your own organization already has on file: confirmed fraud cases, closed accounts and known high-risk devices. Shared industry data adds another layer by flagging identities or devices tied to fraud somewhere else. Neither source should make the decision by itself, but together, they provide context that a single application usually cannot.

The biggest mistake I see is treating one signal as if it tells the whole story. Whether it's a risk score, a device flag, a mismatched identity or a new phone number, each is just one piece of the puzzle. Good fraud detection decisions rarely come from one strong signal. More often, they come from several ordinary signals that don't fit together.

The F.R.O.N.T. Framework

If you take away one thing from this article, let it be a single acronym.

• F: From where? Do the device, IP address and location tell a believable story?
• R: Real identity? Do the identity elements support one another?
• O: Ongoing relationship? Do the phone number and email suggest a real customer or a temporary identity built to disappear?
• N: Normal behavior? Does this application look like a normal customer, or does it fit into a broader pattern?
• T: Trusted history? What do your own records and the industry's shared data already tell you?

Every one of these questions is trying to answer the same thing: Can this applicant be trusted? If the answer isn't clear, the next step doesn't necessarily have to be declining the application. It might simply mean asking another question, requesting additional verification or taking a closer look.

The goal isn't to stop applications. It's to make the best decision possible with the information you have at that moment, whether that means approving it, asking for another document or occasionally preventing a fraud case before it happens. The best fraud decisions rarely come from what's written on the page, but by looking for what information isn't there to give you the full picture.