Application fraud
An identity assembled from parts reuses the parts.
Synthetic identities, stolen documents and mule accounts are built out of details that already exist. The same device across four applications, a document under a second name, an account that took a disbursement last month.
The problem
What this is for
A synthetic identity is designed to pass the checks it knows about. What it cannot avoid is reuse: assembling identities costs effort, so the parts get used again. Seeing that requires reading across applications rather than scoring one, which is the thing an origination flow is not shaped to do.
The workflow
8 stages, and what runs where
Each stage names the module behind it. The chip says whether it runs on your network or ours.
- In your systems
- 2 stages
- At intake
- 2 stages
- On the platform
- 3 stages
- With a person
- 1 stage
- In your systems
An application is submitted
Your origination system posts the application, the applicant and the account, keyed on your own identifier.
- In your systems
Your stack supplies the device identifier
An opaque id your own fraud stack already computed. The platform derives none of its own and measures nothing about a person.
- At intake
The event is accepted or refused, in writing
Every application is accounted for, including the ones no rule fires on. That record is what an examiner asks to see.
- At intake
The details join the ledger
Phones, emails, addresses, device ids, account and document hashes, appended against the applicant with the application they came from.
- On the platform
The cross-reference runs across your own book
A device under four applicants, a document under a second name, an account that has taken a disbursement before. Each writes one sentence with its evidence.
- On the platform
Evidence accumulates on the applicant
Different rules pool as different witnesses; one rule repeating is discounted. The band is recomputed from the rows and is reproducible by hand.
- On the platform
A case opens for your fraud queue
Above the floor you set. If you wired one up, a webhook asks your system to pause the application while a person looks at it.
- With a person
Your team decides, and owns the decision
The case is a prompt with reasons. Any decline, and the notice it requires, is made and sent by you.
What it runs on
Banks, credit unions, fintech lenders, and mortgage, on the lending and onboarding configuration. Verticals are settings over one platform, never separate products.
You supply the applications
Applications, applicants, accounts, device identifiers and document hashes, from your origination stack.
We supply the ledger and the rules
The cross-reference across your own book, the published rules, the case queue, and the audit record of every verdict.
You keep the decision
A pause asks your system to hold an application for a person. Approving, declining and notifying are yours.
Why this shape
What the design buys
It reads across applications
The reuse that identifies an assembled identity is invisible inside one application and obvious across a book.
Reasons an examiner can read
Every finding is a sentence with evidence attached, and the band is reproducible from the stored rows and the published constants.
No model risk added to yours
The rules are published and readable. There is no opaque score to document, defend, or explain to a regulator.
Limits
What it refuses
Stated here rather than found later. Each of these is enforced somewhere in the code, not only written on a page.
This is not a consumer report
It is used for fraud prevention and is never a factor in eligibility, terms or pricing. It is not a credit bureau and does not act as one.
Nothing here declines an application
There is no decline action in the product. The adverse decision and the notice it requires are the lender's, which is where the law puts them.
No body and no habit is measured
No face, no voice, no typing pattern. A device identifier is one your own stack computed and handed over, the way an address is.
Read next
Where to go from here
Lending and onboarding
What the platform reads, and what comes back.
Linked claims
The same cross-reference, pointed at claims.
Data processing
Roles, subprocessors, and what is done with what you send.
The other analyzers
Carrier identity, Double brokering and Linked claims, on the same ledger and the same pipeline.