Put your confirmed-fraud list into the decision
Your fraud vendors return signals, but your confirmed-fraud list is separate from the rules. In one decision flow, the rules read both; your fraud team changes them in the portal, and a provider failure arrives as a value the rules can decide on.
Each entry records why it was added and when it expires
Each application field is matched separately against a confirmed-fraud entry, so the decision knows which fields matched and how many matched on one record. Every entry carries a reason and an expiry date, with the list supplying a default when none is given. The entries are stored in your own Postgres database, not in Decisimo.
Let the rules decide what each signal means
The confirmed-fraud list's answer gives the rule set the number of matching details on one record. The rules decline two or more matches and refer one matching detail to a person, each with a plain-language reason. A provider error is handled in the same rule set, which the fraud team edits in the portal without an engineering release.
After the decision, your Postgres keeps the history
Your deployed flow writes each decision to a table in your own Postgres, and repeat lookups can read a configured cache there instead of calling the provider again. A backtest replays archived decisions through a release against the confirmed-fraud list as it stood when each decision arrived, so later list changes do not rewrite the past.
Connect the fraud vendors you already use
These worked examples show the pattern for fraud providers; any vendor with an HTTP API can connect as a data source through integrations.
- Integrating Fingerprint.com Device Fingerprinting with Decisimo
- How to integrate SEON Antifraud Check into a decision engine
- How to use Trestle IQ Decision Signals for better anti-fraud
- How to integrate FraudlabsPro into a decision engine
- How to integrate Maxmind minFraud Insights into a decision engine
- How to integrate AbuseIPDB into a decision engine
- How to integrate Email Hippo Assess into a decision engine
- How to integrate BINLIST.net into a decision engine
The Antifraud Hub brings together 22 articles on fraud, including IP-address analysis and case management.
Questions we get asked
What is fraud decisioning?
Fraud decisioning is the use of fraud signals and confirmed-fraud records in rules that produce an outcome for an application. Decisimo runs a decision flow that reads your list and vendor lookups, lets your fraud team define what matches and provider errors mean in a portal rule set, and carries a failed provider call into the rules as a value.
Does Decisimo provide fraud signals or a shared blocklist?
Use your existing fraud vendors through their HTTP APIs, and bring your own confirmed-fraud list. Your decision flow reads both, while your rules determine what each provider result or list match means.
What happens when a fraud provider is down?
A failed provider call carries an error value and its HTTP status, and the decision flow continues. Your rule can refer the application with a reason, decline it or take another decision. See how to design an automated decision strategy that keeps working under failure.
Where is the confirmed-fraud list stored?
List entries are stored in your own Postgres database, not in Decisimo. The portal masks every stored detail, and removed entries remain visible with the removal reason, person and date.
Can the fraud team change rules without an engineering release?
Yes. The fraud team edits the rule set in the Decisimo portal. No code is written, so the team can change what a list match or provider failure means in the decision flow.
Bring your fraud rules together
Start free with no credit card. First, describe your use case and validate the decision flow the assistant builds.