From first report to regulator response.
A single system of record for fraud, scam and dispute cases at a retail bank on OYO AI. One case from any channel, a containment playbook with a visible clock, a documented money trail, remediation under second-person approval, and regulator deadlines that escalate before they are missed.
Where it stands. Specified with a retail bank, which is not named, and prepared for user acceptance testing on test data. The figures below are targets from the requirements, not results.
What a fraud and disputes unit is targeting.
Detection is bought. Response is where loss and supervisory exposure sit, because recovery depends on elapsed time. These are the targets in the requirements, each measured against a baseline taken in discovery.
A playbook applies on assessment: services restricted, disbursement flagged, recalls raised to every institution holding traced funds. The clock is on the case and escalates itself.
Every recall has an amount, a recipient and a deadline, and is chased automatically. Partial returns update the case and the recovery measure.
One case instead of a ticket, a call note and an e-mail thread. The case file is produced from the record, so the same work is not assembled twice.
A lift cannot be completed without an identification method and an evidence reference. It is the one control a supervisor can test case by case.
- 0 self-approved remediation decisions
- 0 cases closed automatically
- 0 records deleted: closure is a state
- 0 writes to systems of record in Phases 1 and 2
- 3 languages for screens and customer letters
- 1 case, whatever the channel
- Same-day policy change, without a release
- Every outcome tied to the policy version that produced it
- Deployed inside the bank’s perimeter
The system behind these rules.
Eight screens from the system: the command centre and its reports, then the registers where cases, restrictions and regulator requests are worked.
Screens from the system, with sample data. Names are masked.
Where typical software stops, and where OYO AI keeps going.
Fraud platforms score transactions and raise alerts. General ticketing tools hold notes. Neither is built to prove afterwards which control acted, who decided, and when. OYO AI does not detect fraud; it governs everything after a suspicion exists.
Typical solutions are described by category. Detection stays with the channel and monitoring platforms the bank already runs.
After the alert, most banks run on memory.
A customer reports a scam. The officer records what they can in whatever tool is at hand and telephones the back office for a block. If money can still be recovered, it is leaving while the request travels between people.
Recalls are tracked in the sender’s mailbox, remediation lives in committee minutes, and a regulator’s deadline is remembered rather than tracked. When the supervisory question comes, the answer is assembled from several systems and several people’s memory.
Since 1 July 2026 Armenian institutions must offer the Central Bank’s STOP mechanism, and a lift requires the customer to be identified first. Evidence that is not captured at the moment of the action cannot be reconstructed later. The same pressure is rising elsewhere: UK Finance counted £576.4 million lost to authorised push payment scams in 2025.
One case, and a rule at every hand-off.
Aggregated per party across every path of the money trail, because split transfers are the normal pattern.
One case
Any channel, including referrals from the regulator, the Mediator or the police, opens exactly one case with one reference and one timeline.
The clock
Priority sets a target time from the bank’s own policy. The time left is on the case, and it escalates before it breaches.
The control checklist
Which controls should have acted, which did, and on what evidence. Completed while the facts are fresh, not rebuilt for an inspection.
Two people
The person who investigates cannot approve the remediation, and the officer who applied a case-linked restriction cannot approve its lift.
The chain a case follows.
- 01Report from any channel
- 02Assess and prioritise
- 03Contain
- 04Build the money trail
- 05Complete the control checklist
- 06Conclude liability
- 07Propose remediation
- 08Second-person approval
- 09Customer letter and regulator response
- 10Close with a retained audit trail
Twelve use cases, in the order of the chain.
Each one has its main flow, the rules it enforces, the exceptions it handles and the acceptance test that proves it.
Report and assess
- UC-01Register a fraud report
- UC-02Assess and prioritise a case
Contain
- UC-03Contain an active incident
Investigate
- UC-04Build the money trail
- UC-05Complete the control checklist and conclude liability
- UC-06Refer a case to the AML function
Decide
- UC-07Propose and approve remediation
Restrictions (STOP)
- UC-08Apply and lift a restriction
Respond
- UC-09Answer a regulator or Mediator request
Govern
- UC-10Change a fraud pattern and re-assess parked cases
- UC-11Produce evidence for internal audit or a supervisor
- UC-12Manage the workload of the unit
Ten roles, with duties kept apart.
Intake officer
Registers reports, captures statements and requests immediate blocks.
Fraud analyst
Triage, money trail, control checklist, liability proposal and correspondence.
Head of Fraud and Disputes
Workload, containment oversight and escalations.
Approves: priority overrides and material policy changes
Channel operations officer
Applies and lifts restrictions, and records identification evidence.
Remediation committee member
Reviews the case file and the proposal.
Approves: remediation decisions they did not investigate
Compliance officer
Owns regulator and Mediator responses and AML referral.
Legal liaison
Police referrals, information requests and criminal case references.
Fraud business analyst
Maintains patterns, playbooks, categories, control codes and deadlines.
Internal auditor
Reads and exports everything, and can change nothing.
Fourteen rules, eight of them here.
No evidence, no lift
A restriction lifts only after the customer is identified by an approved method and the evidence reference is recorded.
Investigate or approve, not both
Separation of duties holds on the individual case, not only by role.
No silent closure
No case closes automatically. Taking no action is a recommendation by a named officer.
Sum every path
The amount at a party is the sum across every branch of the trail, never the largest branch.
Prove the gap
Bank control gap is allowed only where the checklist shows a control that should have acted and did not.
Deadlines are policy
Values belong to the bank, are never in software, and count real working days.
Nothing touches the core
Nothing recorded here alters balances, postings or facility terms.
Which version decided
Every configuration change is versioned, and each case records the version that produced its outcome.
Twenty scenarios for the bank’s own staff to run.
Acceptance runs on synthetic data, with the bank present. These are the scenarios where the system has to say no.
| Scenario | Expected outcome | Rule |
|---|---|---|
| Lift with no identification evidence | Cannot complete; attempt recorded | 1 |
| Investigator approves their own proposal | Refused | 2 |
| Case-linked lift by the officer who applied it | Refused; second officer succeeds | 2 |
| Two parallel transfers to one party | Aggregate equals the sum | 5 |
| Incomplete control checklist | Refused, deficiency named | 6 |
| Control gap where the checklist shows none | Refused | 6 |
| Deadline across a public holiday | Computed on working days | 7 |
| Branch user opens another branch’s case | Refused by every route, including export | 11 |
No production personal data is used in the pilot or in acceptance. On the final day of the pilot, the bank’s own analyst makes a live configuration change.
Get the full specification.
The complete document: all twelve use cases with their main flow, exceptions and acceptance test, the fourteen rules, the clocks, the targets and how they are measured, and the twenty acceptance scenarios.
- All 12 use cases from report to close
- The rules, the clocks and the targets, with how each is measured
- The 20 acceptance scenarios and the phased delivery plan
Also read: Textile manufacturing: One roll, from delivery to unit cost. · Greenhouse management: From crop plan to invoice, on one governed model. · IT project management: Delivery efficiency, measured and explained. · Construction management: From first request to the end of warranty.