Run your application fraud decisions in one place

You pay for fraud vendors, keep confirmed fraud in a spreadsheet, and wait on engineering for rule changes. Decisimo brings vendors, your list and rules into one place.

Start free See the process

Application fraud creates losses that arrive late

Stolen or invented identities

Applicants who are not who they say

First-party fraud

Some people never meant to repay

Shared device or phone

Several applications share one identifier

Late loss

It reads as a default months later

Confirmed fraud records

The rules cannot read the spreadsheet

Vendor outage

Applications stop or pass unchecked

The application fraud process from application to release

  1. Application arrives

  2. Connected vendors queried

  3. Confirmed fraud check

  4. Rules decide outcomes

  5. Analyst reviews referral

  6. Analyst updates list

  7. Replay and release

The vendors and rules decide together

  • HTTP API sourcesSeveral providers can be called at once
  • Plain reasonsThe team defines what each response means
  • Failed callsRules read the error and choose the outcome
Fraud rule editor shows an unanswered IP lookup referring and two matched details declining, each with a reason
Application fraud rules refers when the IP lookup did not answer and declines when two or more details match one confirmed-fraud record.

Your confirmed fraud, read by every decision

  • Field-by-field matchesThe decision knows which details matched on one record
  • Reasons and expiryAn analyst adds entries or removes them with a reason
  • Own databaseThe lender's Postgres holds each entry
Confirmed-fraud list table with five live entries, one removed entry, reasons, masked identifiers, and expiry dates
The demo list masks every detail, shows five live entries and keeps one removed entry with its reason.

A rule change replayed against the past before it goes live

  • Revision historyEvery save creates a revision, and two can be compared
  • Backtest datesArchived decisions use the list from each date
  • Release sign-offAn endpoint can require sign-off before deployment
Fraud decision timeline: device dv-5c02e8aa added on 14 Aug; 6 Aug replays approve, 23 Aug replays decline
A device added on 14 August makes the 6 August decision replay as approve and the 23 August decision as decline.

A referral reaches an analyst with what the rules saw

  • Case queueA role's queue receives the referral as a case
  • Review evidenceRuns and evidence sit beside the analyst
  • Versions and authorThe case records what was shown and who replied

Who does what in the fraud team, week to week

  • Rule changesThe team edits them with no code
  • Decision recordsA table in the lender's Postgres holds each input and output
  • Cached lookupsA repeat uses the lender's cache, so the provider is not called

What stays with the lender and its vendors

  • Chosen vendorsThe lender chooses and pays for the data sources
  • Own fraud listThe confirmed-fraud list belongs to the lender
  • Lender's rulesThe result follows the lender's decision logic

Questions we get asked

What is fraud decisioning?

Fraud decisioning combines application data and fraud-provider results to decide whether an application passes, is referred or is declined. Decisimo runs those rules, the lender's confirmed-fraud list and analyst referrals in one decision flow.

What happens when a fraud vendor is down?

A failed call carries an error and HTTP status, and the decision flow continues. See failure handling

Does Decisimo provide fraud data or a shared blocklist?

Decisimo provides no fraud data or shared blocklist. The lender chooses and pays its vendors and brings its own confirmed-fraud list.

Run your fraud decisions in one place

Start free