Transaction monitoring
Evaluate payments, transfers, and withdrawals using amounts, frequency, attempt history, and counterparty context. Apply configured rules and retain the contributing evidence.
Transaction monitoring with the full activity in view.
Bring transaction monitoring, device monitoring, and payment channel monitoring together. Assess payments with customer history, connected activity, and the rules your team defines.
Transactions
1,284 todayLast 24 hoursAll channels
| Reference | What | Parties | Amount | Status | Signal |
|---|---|---|---|---|---|
TXN-00871 Today, 09:31 | Transfer · API | Haruka Tanaka → Meridian Trading Ltd | £18,600.00 | Pending | Rule matched |
TXN-00869 Today, 09:12 | Card · POS | Amara Silva → Northwind Grocers | £64.20 | Complete | — |
TXN-00866 Today, 08:57 | Transfer · Web | Klara Fischer → IBAN CY-8841 | £9,650.00 | Complete | Rule matched |
TXN-00861 Today, 08:40 | ATM · Withdrawal | Ravi Mehta → ATM 2231 | £300.00 | Complete | — |
TXN-00858 Today, 08:22 | Transfer · API | Diana Moreau → Lumen Payroll | £2,480.00 | Complete | — |
TXN-00852 Today, 08:03 | Card · Online | Tomás Herrera → Atlas Travel | £812.40 | Complete | — |
The payment, the device, and the channel.
Connect three perspectives on activity to understand what needs review and why.
Device monitoring
Connect device observations and session activity to customers and transactions. Review new or shared devices and security signals supplied by your applications or providers.
Payment channel monitoring
Review activity across ATMs, terminals, branch desks, and API channels. Connect transactions to the channel records and context supplied by your systems.
One transaction. A much bigger picture.
Look across payments, devices, behavior, linked records, and customer changes. Explore the evidence each layer brings to detection and investigation.
Transaction monitoring
Assess payment velocity, amounts, and counterparties alongside customer history to identify unusual activity.
Where it fits
Combine transaction fields, scoped aggregates, and available risk signals in a configured rule.
Payment activity
Account AC-4821- Current payment
- £8,200 · pending
- Payment history
- 6 outgoing payments · 24 hours
- Attempt history
- 2 failed attempts · 30 minutes
- Available balance
- £8,700 before the payment
- Counterparty
- Meridian Trading Ltd
- Payment instrument
- Linked to account AC-4821
Every input has a role in the review.
Bring payment history and event context together, with clear rules for when detection runs.
Transactions trigger evaluation
Evaluate supported created or updated transactions against configured rules, using current details and available history.
Attempts add history
Retain failed and blocked attempts. Use supported attempt aggregates when a later transaction is evaluated.
Events add context
Record security or customer events and configured signal effects. That evidence can inform later transaction evaluation and investigation.
A rule builder for your risk scenarios.
Combine transaction details, activity history, and retained risk signals. Set the conditions, test them in simulation, and define the response your team needs.
Large payment after a security change
ACTIVECustomUpdated 12 Jan 2026
Conditions
ANDAND
Aggregates›Count
customer·event·30m·type=password_change
greater than0Transaction›Amount / Balance Ratiogreater than0.90
Rule Details
Large payment after a security change
Outbound payment close to the balance shortly after a password change.
Transaction> Created
HIGH
Account takeoverPayments
Conditions you can inspect
Combine supported transaction fields, aggregates, and retained signals around a specific risk scenario.
Changes you can review
Use simulation and rule versions to review a change before applying it to your operation.
An explicit response
Create an alert, add a supported risk signal, or send a configured webhook. Agree how your systems handle the outcome.
Keep matched conditions and contributing activity with the alert. Your institution sets the thresholds and response policy.
Continue into investigationKeep detection changes reviewable
Use simulation, rule versions, and reviewed outcomes to inform the next configuration.
How do transaction, device, and payment channel monitoring work together?
Transaction monitoring evaluates payment activity against configured rules. Device monitoring adds the device, session, and security context your applications supply. Payment channel monitoring brings in the ATM, terminal, branch, or API channel associated with the activity. Your team reviews those connected records together.
What can we configure in the rule builder?
Combine supported transaction fields, activity aggregates, and retained risk signals into conditions. Define actions such as creating an alert or sending a configured webhook. Use simulation and version history to review changes before applying them.
Can we test a rule before publishing it?
Use simulation with supported historical or synthetic inputs. Available history and field coverage affect the result, so validate the conditions needed for your workflow before publishing.
Does a new event automatically run every rule?
Events are retained as context and can produce configured risk-signal effects. The transaction rule path evaluates supported created or updated transactions using that context.
How are actions enforced outside Dossiers OS?
Your systems consume the returned outcome or a configured webhook. Payment holds, account changes, and other external actions depend on the integration you implement.
Explore your monitoring scenario
Walk through transaction monitoring, device monitoring, and payment channel monitoring with your team’s data, rules, and review process.