Enterprise platforms · Banking
Transaction monitoring system development
We develop transaction monitoring systems for banks, lenders and payment firms: the scenarios that detect suspicious activity, scoring that puts the right alerts first, case management for investigators, and reporting of suspicious transactions to the financial intelligence unit. The system works from your own data, can run in batch or in real time, and you own the rules, the models and the code.
Checklist · Financial crime
AML, KYC and fraud system requirements checklist
A requirements checklist for transaction monitoring, fraud detection and document-based KYC systems: data, scenarios and models, alert and case handling, reporting, governance and security.- 01Eight requirement areas written as testable statements.
- 02What to ask for on data quality, lineage and model governance.
- 03Where real-time and batch monitoring each fit.
- 04Seven questions to put to any vendor or development partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Data ingestion and quality
Transactions, accounts, customers, counterparties and risk ratings from core, payments and card systems, normalised into one model with checks for gaps and late data. - 02
Customer risk and profile
Expected activity captured at onboarding, customer and segment risk ratings, and a baseline of normal behaviour for comparison. - 03
Scenario library
Detection of structuring, rapid movement of funds, round-tripping, activity with high-risk jurisdictions, dormant account reactivation and deviation from peer behaviour, each with documented thresholds. - 04
Real-time and batch execution
Scenarios run in batch overnight, intraday or on each payment, using the same definitions so results are consistent. - 05
Alert scoring and prioritisation
Alerts scored on customer risk, scenario strength and history, grouped by customer so an investigator sees one case rather than many fragments. - 06
Case management
Investigation workspace with transaction timelines, linked parties, documents, notes, escalation and a clear status from open to closed. - 07
Suspicious transaction reporting
Drafting, approval and filing of suspicious transaction reports in the format the financial intelligence unit requires, with the supporting file attached. - 08
Tuning and model governance
Below-the-line testing, threshold changes with approval, performance metrics by scenario and a log of every change to rules and models. - 09
Management and regulatory reporting
Alert volumes, ageing, conversion to reports, investigator workload and the evidence of effectiveness that supervisors request.
Reference architecture.
Standards and interfaces
What we design against.
- FATF Recommendations
- Customer due diligence, ongoing monitoring, reporting of suspicious transactions and wire transfer information, which the scenarios and the case file have to evidence.
- Local AML and counter-terrorist financing law
- In Hong Kong the Anti-Money Laundering and Counter-Terrorist Financing Ordinance and the HKMA guideline, with equivalents in each market the bank serves.
- Suspicious transaction reporting formats
- The format and channel each financial intelligence unit specifies, including the goAML platform where it is used.
- ISO 20022 data
- Richer party and purpose data in payment messages gives scenarios better inputs than free-text fields.
- Model risk management
- Documentation, validation and change control for scoring models and rules.
- Data protection law
- Controls on use, access and retention of personal data in cases and reports, including tipping-off safeguards.
Data model
The core entities.
- Customer and profile
- Identity, segment, risk rating, expected activity, beneficial owners and related parties.
- Account and transaction
- Normalised transaction records with counterparty, channel, country, amount, purpose and source system.
- Scenario and threshold
- Definition, parameters, version, owner, effective dates and the approval that put it live.
- Alert
- Scenario, triggering transactions, score, status, assignee and disposition reason.
- Case
- Linked alerts and parties, investigation notes, documents, decisions and escalations.
- Suspicious transaction report
- Draft and filed versions, approver, filing reference and supporting file.
- Tuning record
- Test period, results, proposed change, approval and the production date.
When custom development is the right call.
Controls designed in, not added later.
Strict need-to-know
Access to cases limited by role and case, with controls that prevent customer-facing staff from seeing that an alert exists.Governed rule changes
Threshold and scenario changes require a maker and a checker and are testable before release.Complete audit trail
Every alert disposition, case action and report filing is stored with user and time.Data lineage
The path from source record to alert is documented so a regulator can follow it.Retention and deletion
Retention periods set by rule, with legal holds respected.
From discovery to a system you run.
- 01
Risk assessment and typology review
We read the enterprise risk assessment with compliance and list the typologies, products and channels the monitoring must cover. - 02
Data and scenario design
Source data is mapped and checked, and each scenario is specified with thresholds and the evidence it should produce. - 03
Build and back-test
Scenarios are built and back-tested on historical data, with results reviewed with compliance and tuned. - 04
Parallel run
The system runs beside the current process, and alerts from both are compared before cutover. - 05
Go-live and tuning
Investigators move to the new workspace, and thresholds are reviewed on a schedule using real outcomes.
Relevant work
Where to see our work.
Related
Keep reading.
Common questions.
- What is the difference between transaction monitoring and fraud detection?
- Monitoring looks for money laundering and terrorist financing patterns, usually after the event, and feeds reporting duties. Fraud detection decides in real time whether to block a payment. They share data but use different rules, owners and reports.
- Can the system run on every payment in real time?
- Yes, for scenarios that can be evaluated at the time of the payment. Behavioural scenarios that need history run intraday or overnight, using the same definitions.
- How do you reduce false positives?
- By better data and segmentation, by scoring and grouping alerts per customer, and by below-the-line testing of each threshold so changes are based on evidence.
- Can machine learning be used?
- Yes, as a scoring layer on top of rule-based scenarios, with documented features, validation and monitoring so the model can be explained to compliance and supervisors.
- Who owns the code and the rules?
- You do. The code, the scenarios, the thresholds and the data stay yours.