- Home
- Platform
From monitoring to a documented decision.
Detailed capabilities of the pilot build. Adapters, reporting drafts and deployment need validation for your firm; their status is marked below. For a short overview and planned features, see Capabilities.
Scope reviewed: 21 October 2026
Decision-time evidence versions, new data-quality and delivery controls, and mandatory re-review of changed case proposals are developed and awaiting release to the live demo.
Detect
Rules and screening run over the whole book every night, and on single transactions before they are processed.
Typology rules
Built-in rules for wash trading, spoofing and layering, structuring, pass-through, third-party funding, dormant reactivation, latency arbitrage and bonus abuse. Each is deterministic, with thresholds the firm can read: the same data and thresholds give the same alerts. How the wash-trading rule links accounts.
Activity beyond declared profileNew
Compares a client's deposits over 90 days with the annual turnover they declared at onboarding, pro-rated to the window. Above 1.5 times is medium. Above 3 times is high, and so is above 1.5 times for a student, unemployed or retired client, or USD 25,000 with no declared turnover. The default outcome is no STR: the case asks for updated KYC and source of funds. An STR is recommended only when activity is high and money leaves to a destination that never funded the account; that withdrawal is held. A client already raised for structuring, pass-through, wash trading or third-party funding is not raised twice.
Activity beyond declared profileclient 40388 · sales manager · 90 daysDeclared turnover, pro-rated to 90 daysUSD 14,795Deposits in 90 daysUSD 52,4001.5× medium3× high3.5× → high · no STR · request source of funds and updated KYC
Sanctions screening
Clients and payment counterparties against the UN, OFAC, EU and UK lists, fetched from the publishers and versioned by SHA-256; the UAE Local Terrorist List and MASAK lists by upload. Matching handles Arabic and Turkish name variants and weighs date of birth and nationality. A hit opens a case and holds pending withdrawals. PEP lists are not included; PEP results can be imported from the firm's KYC provider.
Firm-specific rules without code
A typed form, never free SQL: conditions over deposits, withdrawals, trades, logins and bank changes, sequences such as a bank change within 48 hours of a login from a new country, and filters by country or customer risk band. Each version is previewed on 90 days of history and approved by an MLRO who did not write it.
Allow and block listsNew
Firm-defined IBANs, card hashes, wallets, payer names, devices, IP addresses and client ids. A block entry opens a high-severity case at the next run and holds a matching pending withdrawal; the real-time API answers hold for a blocked client, counterparty name or reference. An allow entry belongs to one client and one attribute, and can suppress only third-party funding or dormant reactivation alerts. It never suppresses sanctions or any other rule. An analyst proposes, a second MLRO approves, and every suppression is written to the audit log and counted on the MI report.
Allow and block listsfour-eyes: proposed by one person, approved by another MLROList Type Value Client Status Block IBAN AE07 0331 2345 6789 0123 456 any client active Block Device id dv-7f3a91c2 any client proposed Allow Payer / payee name Fatima Al Mansoori 40211 active The allow entry suppresses third-party funding alerts for client 40211 only, for payments from that payer. Sanctions are never suppressed.
Real-time decision API
Send a deposit or withdrawal before it is processed and get allow, review or hold, with reasons and evidence rows, in the same request. Same thresholds as the overnight rules, no model. Every decision is stored; review and hold open a case. Market-abuse checks stay overnight because they need trade and order data.
Prioritise
The queue puts pending approvals and near deadlines first, and says why each case is where it is.
Auto-close with a written reason
Medium-severity alerts with no STR recommendation and a low score are closed automatically, and the reason is written to the audit log. They can be drawn into QA sampling like any other decision.
Triage recommendation
Each open case is labelled likely false positive, review or escalate from a points sum over listed factors: rule score, severity, earlier closures and STRs for the same client, linked clients with cases, a held withdrawal and the customer risk band. The queue shows the strongest factors and the case shows the full table. It is a recommendation: no model, and it never changes a case.
Queuesorted by approvals, deadline, severity, customer riskCase Triage Deadline Owner MQB-261006-004Structuring Escalatebecause: STR recommended, score 0.86, customer risk high 31 business days left m.alketbi MQB-261006-011Activity beyond declared profile Reviewbecause: high severity, no earlier cases 33 business days left unassigned MQB-261006-017Third-party funding Likely false positivebecause: earlier false positive, same rule and client 34 business days left s.yilmaz Customer risk score
A score from 0 to 100 in three bands. Static factors: country on the FATF lists, legal person, occupation, missing occupation or turnover. Dynamic factors: open cases, STRs filed, deposits against declared turnover, linked clients with cases, own and imported screening results. It orders the queue after deadline and severity, and feeds triage.
Customer risk scoreclient 40388low0–29medium30–59high60–10049- +10Deposits in 12 months above declared turnover
- +20Country on the FATF increased-monitoring list
- +10Open case
- +5Linked client with an open case
- +4Two alerts closed without STR
Regulatory clocks
Business-day clocks support the configured UAE or Türkiye workflow. The firm must verify the applicable authority, report type, start event and holiday calendar. A clock is a review aid, not a universal filing deadline.
Assignment and workload
Each open case has an owner. An MLRO assigns or reassigns; an analyst takes an unassigned case or releases their own. The queue filters by "assigned to me" and "unassigned" and shows open cases per reviewer. Every change is audited.
Investigate
One case file holds what the reviewer needs to decide, including how the alert was reached.
Why this alertNew
When a case is created, the rule records each condition it evaluated: the threshold in force, the value observed for this alert, and whether it was met. The score breakdown and the threshold version, approved or default, are recorded with it. Later tuning does not change the record. The same table is printed in the evidence pack.
Why this alertconditions and thresholds as recorded when the case was createdMQB-261006-004 · Structuring
Condition Threshold in force Observed for this case Met Deposit band (USD) 8500 – 10000 8620 – 9940 ✓ Deposits in band within 14 days >= 5 7 ✓ Deposits in band for critical >= 8 7 ✗ No trading since the first deposit — yes ✓ Different payment sources >= 1 3 ✓ Score breakdown: 0.55 + 0.03 × 7 + 0.10 no trading = 0.86
Thresholds in force: approved version v3 from Tuning
Reasons and evidence table
Numbered reasons and the records they rest on, with the rows the reasons depend on marked. The rule text is kept as generated; where model drafting is enabled, the model text is shown beside it.
Linked parties
Other clients sharing a beneficial owner, payment instrument, payout details, device or IP address, with their cases, as a table and a graph. Both are printed in the evidence pack.
Linked partiesclient 40917- open case
- STR filed
- cases closed
- no case
Provider results on the caseValidate with your firm
Provider findings can be imported or received through supported beta adapters. KYC, sanctions, PEP, adverse-media and crypto results remain attributed to the provider. Import and webhook paths have different case behaviours; agree the required flow in the pilot.
Decide and file
Record the decision and its reason, then prepare a reporting draft for an authorised person to check and submit.
Maker-checker with reason codes
An analyst proposes filing, approving the recommendation, or closing as a false positive; an MLRO approves or returns it. Nobody approves their own proposal. Every close and no-STR decision carries a reason code. Changed case proposals must be reviewed again before approval or return.
Holds on withdrawals
Rules can record a hold against a pending withdrawal. Closing one case retains any restrictions from other cases; the last release returns it to pending. The payment system must apply the decision; local case status alone is not bank confirmation.
Evidence-bound drafting, optional
Optional model drafting checks sentence-level evidence references and rejects invalid output. References support review; they do not establish that a claim is true. Identifiers are tokenised, but free text still needs a privacy check.
goAML XML and MASAK draftsValidate with your firm
goAML XML and MASAK content drafts, with pre-export checks. FIU schemas, indicator codes and sector mappings require validation. Submission is carried out by an authorised person in the authority’s system; STR/SAR, STOR and sanctions freeze reports are separate report types.
Versioned evidence packs
Each proposal and final decision saves its own evidence version, with a fixed transaction window, rule and model metadata as recorded, a SHA-256 fingerprint and a link to the previous version. Download the saved JSON or print in English, Arabic or Turkish. Current working records are shown separately; original source-document archives and frozen goAML/MASAK submission files remain planned.
Govern and prove
What the board, the internal auditor and the regulator ask for, produced from the same records.
Coverage matrix with typology referencesNew
For each rule: the red flags it covers, the parameters in force, the data it needs and whether that data is loaded, alerts in the last 90 days, and the typologies not covered yet. Each rule carries AMLTRIX technique ids and FATF and regulator references, also shown as chips on its cases. Where an AMLTRIX fit could not be confirmed it is marked "to verify", never guessed. The matrix exports as CSV for auditors.
Coveragetypology references as of 7 Oct 2026Rule AMLTRIX FATF / regulator Alerts, 90 days Structuring T0016T0016.005FATF R.10FATF R.20CBUAE TM/SS14 Wash trading T0094.002T0101FATF 2009CBUAE TM/SS3 Activity beyond declared profile T0040*T0011FATF R.10TR RoM (2008)6 Latency arbitrage no AMLTRIX techniqueFATF 20182 * to verify: the fit is not yet confirmed on framework.amltrix.comExport CSVThreshold tuning with backtest
Edit a rule's thresholds and run a dry run over the loaded data: which alerts would be added or removed, and how earlier cases of the same rule and client were decided. A tested set is saved as a proposal with a rationale and approved by another MLRO. Each run's audit entry names the threshold versions used.
QA sampling
An MLRO draws a reproducible sample of decided cases: a random share, plus every auto-closed case above a chosen score. Another MLRO, never the one who made or approved the decision, records agree or disagree with a note. The page shows a QA score per reviewer.
QA score per reviewersample QA-2610-01 · seed recordedm.alketbi22/24 · 92%s.yilmaz18/19 · 95%rule (auto-close)27/30 · 90%Score = agreed ÷ reviewed. A reviewer never QA-checks a decision they made or approved.
MI report for the board pack
Alerts and outcomes per rule, false-positive rate, STR conversion, ageing, deadlines met and missed, disposition reasons, decisions per reviewer and allow-list suppressions, over 30, 90 or 365 days. Printable.
Hash-chained audit log
Every action, by the platform or by a person, is appended with the hash of the entry before it, and the chain is re-checked each time the log is opened. The database refuses updates and deletes on the log.
Retention with maker-checker
One retention period per firm, five years by default in the UAE and eight in Türkiye. A purge is proposed with its dry-run counts and approved by a different MLRO; a purged case leaves a tombstone with its evidence-pack hash. The audit log is never deleted.
Connect and deploy
Data comes in from files, connectors or the API. Case events go out to the tools the firm already uses.
Files first
End-of-day CSV files for clients, trades, transactions, logins, orders, bank-detail changes and bonuses, uploaded or pulled nightly from S3-compatible storage, Azure Blob Storage, HTTPS or SFTP with a pinned host key.
Connectors, in betaValidate with your firm
MT5 Web API and cTrader, Praxis Cashier and B2Core, and KYC, screening and crypto providers by signed webhook or read-only API. Built against each vendor's published documentation and validated with the firm's own account during the pilot. All integrations and their status.
Connection wizard
For each platform: what the firm's side has to set up, the outgoing addresses to allow, the credentials, then a step-by-step test (address, network, TLS or host key, sign-in, permissions, data) that names the failing step and what to do about it.
Notifications and SIEM export
Case events to Microsoft Teams, Slack or a signed webhook, carrying identifiers and a link only, never names or amounts. The audit log is pushed to a Splunk HTTP Event Collector, or read by a SIEM with an API key limited to that.
Accounts, two-factor and SSO
Analyst, MLRO and administrator roles; TOTP two-factor authentication the firm can require for everyone; OpenID Connect single sign-on; server-side sessions that end as soon as they are revoked. SAML is not supported.
Where it runsValidate with your firm
Container packaging and an installation guide for the firm’s cloud account or servers, plus a dedicated pilot option. The target environment, region, recovery and security settings need acceptance with its IT team. The interface is in English, Arabic and Turkish.
Background reading
- Wash trading detection at FX/CFD brokersHow accounts are linked and what a wash-trading report should contain.
- Bonus abuse and latency arbitrage at CFD brokersThe two platform-abuse rules, their defaults and when they lead to a report.
- CBUAE transaction monitoring requirementsWhat the CBUAE guidance expects from monitoring, tuning and QA.
- goAML STR filing guide (UAE)Filing an STR through goAML, field by field.
- MASAK ŞİB filing guide (Türkiye)The MASAK suspicious transaction report and its ten-day clock.
- STR deadline calculatorCount CBUAE and MASAK deadlines in business days.
See it on your own data
The sandbox runs the same build on a synthetic broker or payments book, or on your own CSV files with identifiers tokenised in your browser. A pilot runs for one quarter in its own deployment, alongside your current process.