Unit21, Sumsub, Feedzai and ComplyAdvantage are worth comparing on the events your payment systems actually send. Look at Feedzai when behavioral profiles and investigations are in scope. If the team needs customer risk and monitoring cases to share context through an API, include ComplyAdvantage Mesh. Give every candidate the same sample, including a settled payment and a late reversal.
An identity check opens the account. Monitoring follows what happens once money starts moving. The two can share customer context, but an analyst investigating a payment also needs to see the transactions, the rule that fired and the information available at the time.
Unit21 gets 8/10 from us for a fintech rebuilding its monitoring rules. We'd start there because its documented backtesting gives the team a way to try rule changes against past activity. We'd want to replay our oldest usable events before paying for the product. A reversal that arrives late would go into the first batch. If the team mainly needs to share customer and transaction context with its onboarding reviewers, we'd include Sumsub in that trial.
Define what a transaction event means
Start from the payment ledger. A payment may be authorized, settled, reversed or refunded. Each step may produce an event and each has a different effect on balances and monitoring. Decide whether the rule needs attempted activity, settled activity or both. Do not count the same movement twice because it appeared in two messages.
Agree on a minimal event model: stable transaction ID, event ID, source timestamps, amount, currency, status, customer and counterparty references, and any fields needed for the policy. Separate the time an event happened from the time you received it. A reversal arriving late should remain tied to the original transaction. If you convert currencies, record which amount and reference rate the rule used rather than recomputing history silently.
Before buying software, map those fields from your real payment sources. A rule that looks for unusual activity can misfire if one payment rail omits its external reference or passes signed amounts differently. Include people who own settlement and reconciliation in the design. They know which event looks final in a webhook but is still provisional in the ledger.
Compare vendors against a replay exercise
| Platform | Publicly described capability | What to prove with your data |
|---|---|---|
| Unit21 | Configurable rules, historical backtesting and investigative workflows | Compare alerts from two rule versions on the same time window |
| Sumsub | Transaction rules, configurable scenarios, review and status webhooks | Reconcile transaction events and analyst decisions to the corresponding internal IDs |
| Feedzai | Rules and analytics with customer profiling, investigation and cases | Explain why a scenario fired and how the investigation used the transaction history |
| ComplyAdvantage Mesh | API integration for transaction monitoring and configurable case workflows | Test the event contract, configuration changes and export for the purchased modules |
Unit21 describes historical backtesting as part of its transaction monitoring product. Ask what history must be ingested and how the system treats changes to the event schema. A replay is more valuable when you can compare decisions under both versions of a rule without permanently changing your active case queue.
Sumsub documents ready-made and custom rules, a transaction API and webhooks for outcomes such as hold or awaiting user. Test the same status your application consumes in production. Feedzai describes a combination of rules, models and investigator tooling. Ask for a worked investigation showing which fields were decisive. ComplyAdvantage documents API-led monitoring and case stages in Mesh. Check which cases can be exported from the modules on the quote.
Build a small replay that can expose data problems
Use a bounded historical or synthetic fixture. Include a normal burst of transactions, a pattern your policy says should alert, a duplicate delivery, an out-of-order refund and a missing counterparty reference. Preserve the expected event sequence and expected outcomes so the same fixture works for each candidate. If historic records are used, minimize or transform sensitive data as the approved evaluation allows.
Measure three things: events successfully ingested, alerts you expected to find and analyst minutes per investigated case. Read the missed cases. A candidate might fail because of a rule configuration, a bad translation from your ledger or a product limit. Those have different remedies. An unexpected alert on an ordinary refund is similarly useful if it shows where your data and the rule disagree.
In the sandbox, test a burst at the busiest time you expect and one event from a system that was offline. Ask whether late data is included in the relevant window and whether rules can be rerun without creating duplicate analyst work. A historical replay and a recovery replay are different exercises. Give both an acceptance criterion.
Review what happens after an alert
A rule can create an alert that needs a reviewer. Record the alert, the case outcome and the payment action separately, and specify which role can move each one forward. When the analyst clears a case, the payment should follow the decision policy you set for it. If the case groups several payments, keep each original transaction reference visible.
Have an analyst use the case view for one synthetic scenario. Can they tell which rule version fired, what data was present and which related activity was considered? Can another analyst reproduce the rationale after the case changes owner? Ask whether the approval to change a rule can be kept separate from the permission to resolve a case.
A reliable workflow also handles cases that were created in error. If a processor repeats a webhook, the investigator should not need to clear a second alert manually just because the application failed to deduplicate. Confirm that an export contains enough history to reconcile the closed case with its original alert and payment. Keep the reporting path aligned to the actual policy and jurisdiction rather than assuming a vendor's reporting feature applies universally.
Test the permissions around rule changes
Ask a reviewer to propose a change to a detection rule and have a separate authorized person approve it. Keep a record of the previous version, rationale, effective time and the result of the replay. If the rule changes during an investigation, the analyst should still be able to see the version that generated the alert. The administrative log should make the boundary between proposed and active settings clear.
Test rolling the change back without deleting old alerts. Count the number of approvals, deploys and data loads that requires. If the vendor needs to make the change for you, include that delay in your estimate. A product's ability to adjust a threshold is much less useful if your team cannot safely test and undo an adjustment when policy or upstream data changes.
Plan deployment from a parallel run
Feed the chosen product a shadow copy of events without using its results to change customer permissions at first. Compare the queue with the current process and investigate significant differences. Check the time it takes for the first and last alert to appear, not just a vendor's response to a single API call. Agree who watches ingestion failures and how missed periods will be recovered.
The quality assurance and testing service overview is relevant when designing the acceptance fixture. The guide to KYC providers for custom business applications covers the initial identity context; transaction monitoring should consume the relevant customer state without relying on the onboarding vendor to explain every payment.
Before ending the trial, pick one alert on a reversal that arrived out of order. Ask an analyst to explain it using the case record. If the original payment or the rule version has gone missing, add that to the acceptance criteria and replay the case before switching on live decisions.