Digital onboarding fraud prevention is the set of controls that stop accounts opened online or in an app from being used to steal: at the moment of opening, by checking the applicant's identity and device, and in the weeks after, by checking the account's behaviour against what its opening file said it would be. The second half is where most of the loss is decided, and it depends on inputs most banks hold in separate places: the opening file from the identity verification service or a fintech partner, device and session data from digital banking, the transaction history in the core, check images in document imaging, and the fraud engine's scores. Botminds' New Account Fraud Detection reads those together for each new account; this page is the checklist of what a bank needs to bring for that, or for any program like it, to work.
Examples come from the solution's sample data on fictional people and companies, at a fictional sponsor bank, Tessaly Community Bank.
Digital onboarding fraud prevention: eight inputs to bring on day one
- The opening file, as received
Identity result and score, documents and selfie checks, stated occupation, expected activity and purpose. The account’s own promise, to be held to.
- Device and session data
Device identifiers, IP addresses and login history from digital banking. The only way to see who controls the account now.
- The core transaction history
Every deposit, transfer, hold and restriction, with timestamps. What the account actually did.
- Check images and returns
From document imaging. A check’s payee, payer, stock and memo say more than its amount.
- The fraud engine’s scores and held items
Keep them; a score is a reason to look, and a held transfer is evidence.
- Each partner’s feed and agreement
For accounts opened in partners’ apps: the required fields, the feed schedule and the notice windows.
- Your reason codes and fraud policy
Thresholds, review windows, hold rules and the list of reasons a restriction may rest on.
- Last year’s outcomes
Accounts closed for fraud and a sample that stayed good, to test the settings before they run.
What is digital onboarding fraud?
It is fraud that enters through a remote account opening: a stolen identity, a synthetic one, a document altered or generated by software, or a real person opening an account to rent to someone else. FinCEN's study of identity-related suspicious activity in 2021 found that 13% of such reports, "approximately 323,000 filings", described attackers exploiting "weak or insufficient verification, or circumvent verification altogether" (FinCEN, Identity-Related Suspicious Activity: 2021 Threats and Trends). FinCEN also found that "Financial institutions and other victims appeared to have more difficulty identifying impersonation when they lack an authoritative source to compare identity documentation and evidence."
The word that matters in that research is "onboarding" as a period, not a moment. FinCEN describes the split plainly: "Some financial institutions successfully identify false records during customer onboarding or during transactions and deny attackers' attempts. Others only identify concerns after opening accounts, accepting funds, or funding loans." A program that treats the identity check as the whole of onboarding is betting that every fraud shows at the door.
What data do you need to prevent onboarding fraud?
Two kinds: what the applicant said and showed at opening, and what the account has done since, with the time each was known. The checklist above is the full list. Three of the eight inputs are the ones banks most often cannot reach quickly. Device data sits in digital banking, often with its own retention rules. Check images sit in a document system designed for retrieval by item number, not by account. And partner opening files arrive in each partner's format, on each partner's schedule.
Where each input usually lives, and why the fraud review needs it
| Input | Usually held in | What it lets the review do |
|---|---|---|
| Opening file | Identity verification service; partner onboarding feed; branch account opening system | Compare the account’s life with the occupation, income and purpose it was opened on |
| Device and session data | Digital banking platform | Spot a change of control, and link accounts that share a device across partners and branches |
| Transactions and holds | Core banking system | See every credit and debit in order, and apply a hold or restriction |
| Check images and returns | Document imaging | Read payee, payer and stock; match checks from one book across accounts |
| Scores and held items | Fraud detection engine | Start a review, and keep the engine’s own holds as evidence |
| Partner feeds and agreements | Partner integrations; contract repository | Know which fields are required, when files are late, and how fast each partner must be told |
| Reason codes and policy | Fraud policy; case tool | Make every decision countable and comparable |
| Outcomes | Case tool; charge-off records | Replay settings on closed accounts before they run |
How do deepfakes affect account opening?
They make the documents and faces presented at a remote opening less trustworthy as proof. In respondents' accounts gathered for the Treasury's 2024 report on artificial intelligence in financial services, the threats included "criminals thwarting customer identification programs through document and image manipulation or creation (e.g., “deepfake” images)" (U.S. Treasury, Artificial Intelligence in Financial Services, 2024). FinCEN's alert of the same year reported that "malicious actors have successfully opened accounts using fraudulent identities suspected to have been produced with GenAI" and used them to launder the proceeds of other frauds (FinCEN Alert FIN-2024-Alert004).
FinCEN's red flags for this are mostly about behaviour around the check rather than the image itself: "A customer uses a third-party webcam plugin during a live verification check"; "A customer declines to use multifactor authentication to verify their identity"; "A customer's geographic or device data is inconsistent with the customer's identity documents". It also notes that someone presenting a generated document "may claim to be experiencing repeated technical glitches". How identity verification itself should handle generated media is the subject of deepfake identity verification in the customer identification series; the point for onboarding fraud prevention is that several of these signs only become readable when set beside the account's later device and location data.
Three identity steps, and where onboarding fraud slips through each
What the step establishes: That the presented identity exists, is unique and its evidence is authentic, against authoritative or third-party data.
How it is defeated, and what catches it later: Synthetic or stolen details that pass database checks. Caught later by links: the same SSN, address or phone on other accounts.
What the step establishes: That the validated identity belongs to the person in front of the camera or counter.
How it is defeated, and what catches it later: Altered or generated photos and video, or a real person fronting for someone else. Caught later by a change of device or control.
What the step establishes: That the person logging in later is the same customer, by what they have, know or are.
How it is defeated, and what catches it later: A new device or a takeover after opening. Caught by session data read against the opening device.
Why re-review account opening documents after opening?
Because that is where many generated identities are found. FinCEN's analysis of BSA data "indicates that financial institutions often detect GenAI and synthetic content in identity documents by conducting re-reviews of a customer's account opening documents" (FinCEN, 2024). A re-review is cheap when the documents and the account's history are in one place, and expensive when an analyst must request the partner's file, find the device log and pull check images separately.
The solution's onboarding re-read agent does this for every account in review: it sets each field of the opening file beside what the account has done since, cites the source of both, and proposes a change of customer risk rating where the two diverge. It never re-verifies identity on its own and never edits the customer record; it marks fields as fitting, worth a look or not fitting, and a person accepts or rejects the result. The customer identification rule supports keeping that evidence: the program "must include procedures for making and maintaining a record of all information obtained" (31 CFR 1020.220(a)(3)).
The opening file, re-read against nineteen days of activity
How do you connect onboarding data to account monitoring?
By keying everything to the account and to time. The opening file has to be stored as it arrived, not overwritten by later updates, so it can be compared with what came after. Device and session events need the account identifier attached at the moment they happen. Check images need to be retrievable by account, not only by item. And each event needs the time it was known to the bank, so a later review, or a replay of past accounts, can see the account as it looked on any given day.
The payoff is the analyst's time. The sample bank's own estimate puts the manual rebuild of one flagged account at about 40 minutes, most of it gathering, against a design target of 10 minutes once the inputs are read together. Those figures are estimates for the sample, not measurements, but the split is the useful part: the minutes saved come almost entirely from assembly, not from the decision.
Where an analyst’s minutes on one new account go, by hand and with the inputs joined
By hand · about 40 minutes (estimate)
- Rebuilding the account · 30%
- Re-reading the opening file · 20%
- Finding linked accounts · 25%
- Deciding · 13%
- Notices and referral · 12%
With the agents · 10-minute target
- Rebuilding · 20%
- Opening file · 20%
- Links · 10%
- Deciding · 30%
- Notices · 20%
What systems hold new account data?
At most banks, five: the core banking system for accounts, transactions, holds and restrictions; the identity verification service for opening results; the digital banking platform for devices, sessions and IP addresses; document imaging for check images and returns; and the fraud detection engine for scores and held transactions. A sponsor bank adds a sixth, each fintech partner's onboarding feed, which is often the only place the opening file exists in full. The solution connects to all six; it does not replace any of them, and restrictions and holds are still applied in the core.
What to decide before the first account is read
Inputs are half of what a bank brings; the other half is decisions that only the bank can make. They belong in the written fraud policy and, for a sponsor bank, in each partner agreement. In the solution each is a versioned setting, approved by the model risk manager where it changes what the agents propose.
Settings a bank fixes before go-live, with the sample bank’s choices
| Setting | The question it answers | Sample bank |
|---|---|---|
| Review threshold | Which fraud engine scores send an account to review, by partner and for branches | Fernway 640, branches 700 |
| Review window | How long a new account stays on the new-account watch list | 90 days |
| Fast lane for large deposits | How quickly a large deposit on a very young account must be decided | $2,500 or more on accounts under 30 days: within 4 business hours |
| Checker deadline | How quickly a second person must approve a restriction or closure | Within 2 business hours |
| Partner notice windows | How fast each partner must be told | 1 or 2 business days by agreement |
| Reason and override codes | What a restriction may rest on, and why a person differed from the agents | R-01 to R-12; O-01 to O-06 |
| Agent confidence floors | Below what confidence the agents ask a person instead of proposing | 70% to 80% by agent |
| Retention and masking | How long the trail is kept and who sees SSN and date of birth | Five years from account closure; masked by default |
How fast can onboarding fraud controls go live?
As fast as the bank can grant access to its inputs, which is usually the slow part, and as fast as its fraud policy can be written down as settings. The detection logic itself is not the constraint. A sensible order is to connect the opening files and device data first, because they drive the links between accounts; add check images next, because bust-outs and mule rings so often run through checks; and run the whole set on a sample of the bank's own past new accounts and partner files before it proposes anything live. The step-by-step trace of one account shows what the joined inputs look like in use, and NIST identity assurance levels at account opening covers the identity check that comes before them. To see it on your own accounts, start from New Account Fraud Detection.
The settings, versioned: what each agent may do and how it was last evaluated
Questions people ask
What should be in an onboarding fraud policy?
The red flags the bank watches at and after opening, the response to each, the hold rules for deposits on new accounts, review thresholds and windows, who decides and who checks, notice duties to partners and customers, and how the policy is tested and updated. For banks this sits inside the identity theft prevention program the Red Flags Rule requires.
Is identity verification enough to stop onboarding fraud?
No. FinCEN's identity analysis shows some institutions catch false records at onboarding while "Others only identify concerns after opening accounts, accepting funds, or funding loans". Verification is the first control; reading the account's early behaviour against its opening file is the second, and it catches what the first let through.
Does multifactor authentication help at account opening?
FinCEN names multifactor authentication and live verification checks as practices that reduce vulnerability to deepfake identity documents, and lists a customer who declines MFA as a red flag. It is strongest combined with device data: an account that passed MFA on one device and then moves to another days later is worth a second look.
What is the difference between onboarding fraud and account takeover?
Onboarding fraud starts with an account opened to steal; account takeover hijacks an account a genuine customer opened. They meet in the device data: a new account that changes devices within days looks like a takeover of an account that never had a genuine owner.
Do we need new data to start?
Usually not. The eight inputs above already exist at most banks; what is new is reading them together, keyed to the account and the time each was known.