Real-time AML monitoring
Real-time AML transaction monitoring, switched on scenario by scenario.
Trusted by 130+ financial institutions across 30 jurisdictions
Real-time AML transaction monitoring checks a payment against your monitoring scenarios while it's still in flight, so your system can hold it before it's released.
Everyone agrees detection and action should happen in real time. The doubt is whether that's realistic without a major IT project or a bigger team to run it.
Choose which checks run in real time with Salv, on an integration you already need. Everything else runs as data arrives or on a schedule.
Not every check needs to block a transaction in real time
Set each scenario to real time, post-event or periodic. Use real time for checks that must act before money moves, such as rapid movement of funds in and out. Post-event runs when data is uploaded, by API or batch, with alerts within minutes. Periodic runs weekly, monthly or yearly. Most checks don't need real time.
Sanctions screening runs separately, on its own timing: payments in real time, and customers re-screened several times a day as lists change. A monitoring scenario can check the linked screening alert before it decides.
Set up real-time AML monitoring without a disruptive IT project
Transactions arrive by REST API, connected and tested by an engineer on your side during onboarding. Each real-time scenario adds one check call per transaction, and only runs where that call is made.
Your system then holds, releases or rejects the payment on Salv's answer, the pattern many teams already run for sanctions hits. A scenario outcome can also emit a webhook carrying a custom action, with the conditions set in Salv's UI rather than your own code.
Your compliance team chooses, tunes and tests scenarios it can read and change. Start from the scenario library or build your own, set thresholds and segments, and add a suppression interval so a repeating customer doesn't re-alert every day.
Test on up to a year of your own history. Real-time scenarios look back up to one month, and holding every later payment from the same customer is an action your system takes, on a condition you set in Salv.
The patterns it's built to catch
On transactions: many small payments that stay under thresholds, rapid movement of funds in and out, activity out of line with a customer's usual pattern, and payments to high-risk countries.
On people: several customers on one IP address, a change in risk level, and frequent changes to personal details. The library already covers these typologies, and your own scenarios sit alongside them.
See it on your own data
AML tools that work together
-
MonitoringScenarios you can read, test on your own data and change yourself. Watch payments, customers and counterparties, for AML and fraud.
-
ScreeningScreen customers and payments against sanctions, PEP and adverse-media lists, with matching you configure and lists Salv keeps current.
-
Risk scoringCustomer risk rating on weighted rules built around your framework. Kept current as the facts change, feeding the monitoring and screening that act on it.
Real-time AML monitoring FAQ
A transaction is checked against your scenarios before your system releases it, with hits returned in the response, so the payment can be held rather than reviewed after it's gone.
No. Each scenario is set to real time, post-event or periodic. Real time is for checks that must act before money moves; post-event and periodic cover the rest.
Transactions arrive by REST API, and an engineer on your side connects and tests the integration. A real-time scenario adds one monitoring check call per transaction.
Your system stops it, on Salv's answer. Salv returns the scenario hits and can emit a webhook with a custom action; your system holds, releases or rejects.