The console
From the alert to the suspicious transaction report, in one place
The console brings together the work of your analysts and your compliance officer: handling alerts, investigating cases, preparing the suspicious transaction report, setting your rules and your policy. It speaks the vocabulary of the BCEAO and the CENTIF, in French and in English, and every decision leaves a trace.
Alerts
Alerts that explain themselves, handled from the keyboard
The alert queue is sorted by priority. The open alert sits next to it, with its amount, its corridor, the parties under pseudonyms and the reasons for its score. Your analysts label, escalate or assign without leaving the queue.
Queue and detail side by side
Mine, Unassigned and All tabs, one-step assignment, bulk labelling. The selected alert is in the page address: a link is enough to show it to a colleague.
Built for the keyboard
J and K to move between alerts, L for legitimate, F for fraud, E to escalate to a case. A decision can be undone for a few seconds.
Labelled with your taxonomy
Every label follows your own fraud taxonomy. These labels are what later allows a supervised model to be trained on your cases.
Transactions and profiles
Search and filters across all transactions, CSV export, a page for each transaction, and a profile for each sender, receiver, device, agent or corridor.
Links between parties
The Links page shows the network around a party, an alert or a case, as a graph and as equivalent tables.
Usable on a slow network
The console’s main journeys are checked on every release against a 3G network profile: 400 ms of latency and 400 kbit/s.
Cases and reports
Investigate a case, then prepare the report
An escalated alert opens a case. The case gathers the related alerts, the timeline, comments, the person in charge, the priority and the due date. Once the suspicion is established, the report is prepared within the case itself.
One case per matter
Related alerts are suggested and added in one click. Every event in the case is dated and attributed: who did what, and when.
Four-eyes approval
When your policy requires it, closing a case or filing a report is proposed by one person and approved by another.
The suspicious transaction report
Suspected offence, grounds, facts, measures taken and a table of the operations with totals per currency: the draft is written from the case.
The CENTIF Côte d’Ivoire form
The sections of the official model (order n° 391 MEF/CENTIF of 30 October 2017) are filled in the console, which points out the mandatory entries still missing. PDF in the CENTIF format or in the YARDA layout.
Sealed when filed
When you record the filing date and the CENTIF reference, the report is frozen and its SHA-256 fingerprint shown. The console then checks that the stored copy has not changed.
Every download traced
PDFs and data exports of a report are written to the audit trail, like every action on the case.
Rules and policy
Your rules and your policy, with no developer
Your team writes its own IF/THEN rules in a visual editor, replays them on your history, then has a second person approve them before they act. The choices that are yours to make are gathered on the Organisation policy page.
An IF/THEN editor
Conditions on the transaction, on recent activity, on your lists, on a behaviour measured by YARDA or on a built-in typology. Actions: flag, raise the score or force a decision. The rule is also spelled out in words.
A scenario library
Ready-made rules for money transfer and mobile money, and eight built-in typologies: false reversal, sending right after a SIM swap, mule account, splitting under a limit or at one agent, a dormant account waking up, among others.
Replayed on your history
A version is replayed over 30, 60 or 90 days: hits per day, new alerts against the team’s capacity, overlap with the models. A recent replay is required before any approval.
Approved by a second person
The author of a version cannot approve it. Every step asks for a reason, kept in the audit trail, and an earlier version can be restored.
Lists and sandbox
Block, watch and allow lists, filled by hand or from a file, with an expiry date. The sandbox tests a transaction against your rules without recording anything.
The organisation policy
Alert thresholds set on your labelled history, blocking allowed or not, acts subject to four eyes, two-factor authentication, session length, API key rights, data retention: every change has a reason and a version.
Oversight and compliance
Follow the activity and report on it
The overview shows what needs action now. Analyses, the annual report and the audit trail give your compliance officer what to present to management, auditors and the supervisory authority.
The overview
Alerts to review, amount at risk, flagged rate, confirmed fraud and false alert rate, compared with the previous period, with the most exposed corridors and entities.
Defined analyses
Score distribution against the thresholds, alert funnel, queue ageing, agents outside their usual limits. Every chart has its definition and a table view.
The annual report to the BCEAO
For article 12 of BCEAO Instruction 001-03-2025, the console counts the two points that come from its data: reporting statistics and the map of suspicious operations. The other six are for the institution to write.
The yearly review of the system
For the yearly examination under article 6 of the same instruction, the console gathers the facts of the part YARDA runs: alert performance, changes to models and settings, incidents.
Data health
The state of each feed, imports, connectors and silences. An e-mail warns you when nothing has arrived beyond the delay set in your policy.
The audit trail
A chained record of every act: each entry carries the fingerprint of the one before, and the database refuses any change. Your supervisor reads it in the console and, depending on your subscription, exports it with its fingerprints to check it outside YARDA.
Your team, your access
Four roles: read only, analyst, supervisor and client admin. The client admin invites colleagues, changes their roles and can require two-factor authentication. Every user sees their open sessions and can end them, sensitive acts ask users to confirm their identity, and YARDA support’s access to your space is visible and can be made subject to your approval.
See the console on a demonstration workspace
We show it to you on a workspace with entirely fictitious data, then on a sample of your own transactions during the diagnostic.