Record evidence
Facts arrive from verification sessions, from your own systems or from your own model, each with its source and age.
Fraud & risk
Korala compares each session with the ones before it, scores each customer under the risk policy you write, and keeps each decision with its inputs and reasons. For the customers you monitor, Korala reassesses on its own when evidence changes or goes stale.

The process
Facts arrive from verification sessions, from your own systems or from your own model, each with its source and age.
A published, versioned policy turns the evidence into a score, a band and a decision: none, review, restrict or reject.
Actions land in one queue for your team. Signed webhooks tell your systems what changed.
Turn on monitoring, and Korala reassesses the customer under the same policy when new evidence arrives or a review deadline passes.
Inside the product
The customer timeline keeps evidence, assessments and actions in order, so a reviewer sees why a case reached them.
Read the risk guide →Fictional customer. The policy sent this case to a reviewer.
Fraud across sessions
The same file, the same text or the same details under another name. Korala fingerprints every upload and compares it with earlier sessions.
One person behind many accounts: the same name and date of birth, government ID, address or network turning up again.
Too many attempts too fast, and many applicants from one IP address or subnet.
Tor exits, data-centre and hosting networks, and an IP country that does not match the document.
One browser installation used by several different customers. Opt-in. A match sends the case to a reviewer.
Automation tools and virtual cameras. In development. We will claim it once we have measured it.
Your policy
Inputs, factors, bands and rules in JSON. Validate and simulate a draft, then publish it. Each assessment records the policy version that produced it.
Each assessment stores the exact inputs, the score, the band and the rules that fired, so you can explain the decision later.
An owner or admin can override a result. The override, its reason and who made it stay in the record.
Send your own model's judgment as evidence. Korala accepts it only from the key you name and keeps where it came from.
When a case needs a closer look, an AI investigation brief gathers the customer's evidence, assessments and open actions, and points out saved claims about the same fact that may not fit together. Each suggestion links to its source records, and the reviewer accepts or dismisses it with a reason.
How investigations work →Review what happened
Evidence, assessments, overrides and actions for one customer, in order and filterable.
Open actions across customers in one place, with what raised each one.
Assessment and action events reach your systems signed, with delivery history to reconcile against.
Risk webhooks →With your AI assistant
“Draft a policy that sends anyone on a data-centre network to review, and test it on a few scenarios.”
Publishing a policy stays with an owner. The AI brief above runs inside Korala; this is your own assistant working with Korala.
How AI assistants work with Korala →Build with Korala
Create subjects for people, businesses, accounts or transactions, append evidence and evaluate a published policy through the API. Test keys work only on test data, so you can try a policy without touching live customers.
Common questions
No. A decision of none means your policy requires no restriction. It is not identity approval, and Korala does not change account permissions or block payments for you.
No. Scores come from your published policy and the checks it reads. The optional AI brief helps a reviewer compare claims; it never changes a score or a decision.
Missing evidence leaves the assessment incomplete or sends it to review, as your policy says. It never counts as a pass, and evidence older than the policy allows no longer counts.
Your organization defines its obligations, its policy and its review process. Korala records what you checked and what your team decided.
Write a policy, simulate it on test scenarios and run it on test customers before anything touches live data.
