Transaction monitoring on your risk rules

Six dimensions, and they combine:

• Size — transaction value
• Frequency — how often
• Velocity — how much, how fast
• Counterparty — who is on the other side, screened against PEP and sanctions lists
• Jurisdiction — including high-risk corridors
• Profile deviation — departure from the customer's own baseline, typically over 90 days

Combining them is what makes the rules useful. A pattern such as repeated transfers just under $10,000 can be expressed directly, where no single dimension would catch it.

By looking at the sequence, not the transaction.

Structuring is the practice of breaking a large amount into deposits that each sit below a reporting threshold. Every individual transaction is unremarkable, which is the entire design, and reviewing them one at a time will never surface the pattern.

A rule that combines size, frequency and velocity sees it: twelve transfers in 24 hours, each just under the threshold, is a shape, not an event. Monitoring at the pattern level is the only way that becomes visible, which is why periodic file reviews do not substitute for it.

You set them, per rule and per risk tier. We help calibrate during setup, and you adjust as your risk assessment changes.

Tiering the thresholds is what makes the risk-based approach operational. A high-risk customer should trip a review at a level a low-risk customer would not, and applying a single threshold across the whole book means either drowning in alerts from ordinary customers or missing genuine activity from risky ones.

Setting them yourself is not a gap in the product. Your risk appetite is yours to define, and a vendor default presented as a compliance standard would be worth very little under scrutiny.

Three ways, and the third one matters most in practice.

Thresholds are tuned per risk tier, so ordinary behaviour from low-risk customers does not generate alerts. Rules that produce noise show up in reporting, so you can identify and adjust the specific rule instead of raising every threshold indiscriminately.

Most importantly, alerts carry full context: the rule that fired, the transactions involved and the customer's background together. That means even a false positive is quick to close. A monitoring system's real cost is rarely the alert volume itself; it is the minutes an analyst spends assembling context before they can dismiss one.

The rule that fired, the transactions that triggered it, and the customer context, presented together.

Where an alert needs more, Caspar assembles the background on the people and companies involved (court records, associations and linked entities) without the analyst leaving the case.

The design goal is that review takes minutes instead of becoming a research exercise. An alert that arrives as a bare flag against an account number transfers the entire investigative burden to the analyst, and that is where monitoring programs quietly fail: not by missing alerts, but by generating more than anyone can properly examine.

Yes, and this is where the record structure earns its keep.

When an analyst confirms an alert is suspicious, the record already contains the transactions, the rule that fired and the full review history, which is precisely the evidence a suspicious matter report needs to reference.

Reporting entities must notice and report suspicious activity, and that obligation implies a system watching transactions, not periodic file reviews. Having the evidence assembled at the moment the suspicion forms is what makes the report straightforward instead of a reconstruction exercise against the clock.

Through the API, either as transactions occur or in batches.

Monitoring runs on the data you send. No direct access to your core banking or ledger systems is required, which is usually the difference between a project that can start this quarter and one that needs an infrastructure review first.

Alerts and outcomes can be pulled back into your own case management, so monitoring does not have to become a separate system your team works in.

For as long as the program's retention period specifies. The range runs from no retention up to 84 months (seven years, matching the AML/CTF record-keeping requirement) and the default is 12 months, so the seven-year setting has to be chosen, not assumed.

The outcome is retained alongside the alert, which matters more than the period itself. An alert record showing only that something fired is of limited value; one showing that it fired, was reviewed, and was closed for a stated reason by a named analyst is the evidence that the program was operating.

Records can be exported at any time. If your obligation is the full seven years, set the retention period accordingly when the program is created. Changing it later does not bring back data already aged out.