First-party fraud detection at first deposit

A first-party fraud control at funding is a hold or a referral with cites, issued before the first deposit posts as available balance. The score is not a completed SAR. It is not a reason to auto-release because onboarding KYC already passed.

First-party fraud at first deposit is the pattern where the person who opened the account will later dispute, bust out, or abandon a synthetic identity. Until the money clears, you still have a control. After availability, the bank is funding the scheme.

Treat the deposit as the decision object. Pull onboarding for context. Do not let a green KYC outcome close the case. Identity verification asks whether this person matched a document and a database. First-deposit scoring asks whether this funding event looks like synthetic assembly or bust-out setup. A clean agentic KYC orchestration run can still sit on a device cluster, a mule-adjacent network, or a velocity pattern that only appears when money moves.

Vendors in this class, including Featurespace, Feedzai, Temenos, and peers, score deposit and payment events using device, behavioral, and network signals. Use that output as a scoring layer, not a filing, and not as permission to skip the hold policy you wrote for first funds.

Define "before funds clear" on each rail: ACH pending, card credit, cash, wire, RTP. Bind the score to that state. If the model returns after availability, you have a recovery tool, not this control.

A usable score is a packet a fraud analyst can defend in a callback, a QA sample, and a SAR narrative. Cite three signal families. If one is missing, say so. Do not invent it from KYC.

Device: same fingerprint or emulator farm as other new accounts; recent factory reset; mismatch between the onboarding device and the deposit device. Treat jailbreak or rooted signals as elevated only where policy says so, not as automatic fraud. Pair with liveness and deepfake detection from onboarding as context only. Passed liveness does not clear a deposit on a recycled device cluster.

Network: shared emails, phones, addresses, or funding instruments across new accounts; first deposit from a source already tagged mule-adjacent; reuse of a routing number or debit card across unrelated CIFs; IP or geolocation that collides with a bust-out cell. Name the edge (instrument, identifier, counterparty) so the analyst can pull related CIFs without reverse-engineering the model.

Behavior: time from open to first credit; deposit size versus the product's typical first fund; outbound setup (bill pay, P2P, card, wire) before inbound settlement; a funding session that does not match onboarding (new browser, copy-paste of account numbers, retry storms); velocity of applications or deposits from the same cluster.

State what the score is not citing. A thin credit file is not bust-out. New-to-bank is the population, not the typology. If the product is a credit line, this control still gates the first money in; limit setting is separate. See thin-file credit limit calibration.

The model recommends auto-clear under policy, hold, or refer. A human owns hold release and any SAR.

Hold: the first deposit does not become available balance until an analyst, or a documented dual-control rule, releases it. The customer-facing reason should be operational (deposit under review). The internal packet still names the cites.

Refer: funds stay in the pending state you defined, and the case lands in a queue with an SLA. Refer is for hits that need a person, not for every new-to-bank account.

Clear: the score and the policy gates passed. That is not "KYC passed, so fund." That is this deposit did not meet hold or refer criteria.

When the packet also looks like layering, structuring, or a mule pass-through, do not end at fraud ops. Hand the same cites to AML with the deposit still held. AML case disposition at funding is the sibling control. Fraud decides first-party and bust-out. AML decides whether the funding event is a BSA case. Share the packet. Do not share an auto-file.

If the first credit looks like test-in, larger-in, then out, keep the hold and compare against mule account detection at top-up. Bust-out and mule use can sit on the same CIF. Do not close this control because the mule model did not fire.

A new DDA opens on a weekday evening. KYC, document scan, and liveness pass. Later the same day a first ACH credit arrives from a consumer bank account whose owner name is close to, but not identical to, the CIF. The scoring layer flags hold.

The packet should show the device ID colliding with other CIFs opened in the same period, including accounts that already have returns on first credits; the funding account as an inbound source on those related CIFs; a deposit session on a different device than onboarding; short time-to-fund for the product; outbound P2P enrolled in the same session as the deposit inquiry, before the ACH settled.

The analyst does not release because KYC was green, and does not file a SAR because the score was high. They keep the ACH pending, suppress availability, and work the graph: same device, same funding source, name variance. If related CIFs show the same assembly pattern, the case stays fraud with cites. If the name variance is a maiden name or DBA and the device is a shared household phone, they document that alternative and release under dual control. The decision is written against the cites, not the onboarding stamp.

If the graph, funding source, and outbound setup still look like synthetic assembly or bust-out prep, escalate per SAR procedures. The narrative starts from the cites and related CIFs. The model score is a detection input, not the filing.

Releasing because onboarding KYC was green is the default leak. KYC gates identity evidence. First-deposit scoring gates the first money. If a passed KYC is a hold override, the queue learns to ignore the only window you have. Make KYC context in the packet, never a release code.

Treating every new-to-bank customer as bust-out floods the queue. New-to-bank is the book you are funding. If models or rules fire on "no prior relationship" alone, analysts stop reading cites. Bust-out needs a pattern: deposit-then-outflow setup, instrument reuse, device or network collision, or funding behavior that does not match a genuine first fund. Score the event, not the segment.

Filing a SAR from the score alone is not an investigation. A high score is not knowledge of a violation. Auto-filing from a vendor score (Featurespace, Feedzai, Temenos, or any peer) produces unsupportable narratives and trains the model on filing behavior instead of confirmed typology. The human decides whether the cites, the graph, and any customer contact meet the filing standard. Document no-file reasons. Keep hold-or-release separate from the BSA decision.

Two smaller leaks: scoring after availability (recovery, not this control), and auto-releasing when a second, cleaner device appears (device hopping, not remediation). Require the original cites to be addressed, not replaced.