DetectX® checks every incoming and outgoing payment as it happens. It screens the counterparty against sanctions lists and your own blacklists, tests the payment against the rules your compliance team sets, and holds anything suspicious for your analyst to decide. Clean payments go straight through.
One Platform. Total Compliance.
One Platform. Total Compliance.
Transaction Filtering screens incoming and outgoing payments in real time, against sanctions and blacklists and against your own business rules. Instant Payment Transaction Filtering runs on the same engines.
Two engines, one decision. Every payment message from your core banking system is checked twice: the counterparty against sanctions lists and your blacklists, and the payment against your business rules. A hit on either holds the payment. Everything else goes straight through.
The right party, by direction. On an outgoing payment, DetectX® screens who receives the money and where they are.
On an incoming payment, it screens who sent it and what the payment says.
Example data.
Scored, then tuned. The name is scored against every list entry. Tuning tables, including a White List filled from analyst decisions, keep known false hits from stopping payments.
Your policy, as rules. Rules are built from your own data and tables, combined into a rule set, and checked against every payment.
Held only when it should be. Each payment is screened on its own. Clean payments are released without intervention; a hit is held, returned to the core system and worked by your analyst.
The payment message reaches DetectX® from your core banking system.
Name Screening and your business rules run on this payment alone.
A hit holds the payment. Without one, it goes straight through.
The hold goes back to the core system, which marks the payment as suspicious and ready for post-processing.
Your analyst handles the alert in AlertViewer, through your configured workflow. Cleared matches go on the White List.
Two questions, two tools. Transaction Filtering decides on the payment in front of it, before it posts. Transaction Monitoring looks back across a customer’s transactions over time.
One payment, checked as it happens. A hit holds it before it posts.
A customer’s transactions over a period, analysed together in a batch run.
Both run on the same rules engine and raise alerts in the same AlertViewer. Example data.
Transaction MonitoringStopping a payment is easy. Releasing the right ones is the work.
A filter that holds too much stalls good payments, and one that clears too widely lets the wrong one through. DetectX® checks every payment before it posts, lets clean ones go straight through, and keeps every clearance tied to the exact pairing your analyst cleared.
Incoming and outgoing payments are screened before they post: who is being paid on the way out, who is paying on the way in. A hit holds the payment until your analyst decides.
Instant PaymentA payment with no hit goes straight through, with no intervention. Your analysts spend their time on the payments that need a decision, and customers aren’t kept waiting on the rest.
Name Screening IntelligenceYour compliance team writes the rules once, from the payment fields, customer data and tables such as country risk. The rule set runs on every payment.
Business Rules Design & Engine
amount > 1,000,000 and currency = CHFcounterparty country in country riskaccount in blacklistcustomer PEP status = foreignWhen your analyst clears a match, it goes on the White List. Later payments between the same customer and counterparty go through without a new alert.
WorkflowsEach White List entry holds the customer and the list entry or rule, and optionally the counterparty’s IBAN. A different list entry, rule or account raises a new alert.
The DetectX® PlatformEvery hold is worked in AlertViewer. Deleting a White List entry needs a written comment, so every change to what is cleared can be shown later.
Name ScreeningMost payment filters stop the payment. DetectX® clears it once.
In production
Three ways in, depending on where you are.
Each one is a conversation with the people who build DetectX®, with no obligation.
Watch Transaction Filtering work through real alerts with a product specialist.
Bring your data, volumes and core banking system. We map where DetectX® fits.
Speak with a compliance team already running DetectX®.
Try it yourself: five steps, from a stopped payment to a recorded decision.
DetectX® screens every payment your core banking system sends it, before the payment moves. Names are checked against your sanction and blacklists, the payment against your business rules, and a payment with a hit is stopped for your analyst. Every step is yours to drive.
Illustrative exampleInvented Names & Data
List 90210004411
Start with Transaction Filtering. Add what you need next.
Every DetectX® solution runs on the same underlying platform, sharing its capabilities, AlertViewer and audit trail. Pick one to see what it does.
What compliance teams usually ask before they choose Transaction Filtering.
Transaction filtering is the check of each payment, before it posts, against sanctions lists, internal blacklists and a bank’s own payment rules, so that a payment to or from a listed party is stopped in time. DetectX® Transaction Filtering screens the counterparty in every incoming and outgoing payment, tests the payment against your business rules in the same check, and holds it for your analyst on a hit. Clean payments go straight through, and instant payments are filtered on the same engines.
Transaction filtering decides on one payment as it happens; transaction monitoring looks for patterns across a customer’s transactions over time. In DetectX®, Transaction Filtering checks only the payment being made, in real time, and holds it on a hit. Transaction Monitoring analyses a customer’s transactions over a period in a periodic batch run, for example daily, and raises an alert for review. Both use the same rules engine and AlertViewer.
DetectX® screens the counterparty, not your own customer. On an outgoing payment, it screens the beneficiary’s name and address. On an incoming payment, it screens the sender’s name and the remittance information. Your customer is already screened by Name Screening when they are loaded into DetectX®. Payment messages arrive from your core banking system in ISO 20022 format.
Your compliance team builds rules from fields in the payment and the customer data, and from tables you maintain, such as country risk or stop words. Typical rules hold a payment above an amount for a given currency, a payment to a counterparty in a high-risk country, a payment to a blacklisted counterparty, bank or account, all offshore or SWIFT payments, or a payment by a customer who is a foreign PEP. Conditions combine with AND and OR, and the rules are grouped into a rule set that runs on every payment.
No. A clearance covers one pairing. When your analyst clears a match, DetectX® stores the customer together with the list entry or the rule that was hit, and, if your bank switches the setting on, the counterparty’s IBAN. Only later payments matching that entry go through without a new alert; a different list entry, rule or account is held again. Deleting a White List entry needs a written comment.
How Generali Switzerland moved from name screening at onboarding in 2007 to real-time screening of every outgoing payment in 2024, on the DetectX® platform.
Read the case studyBrochureDetectX® Anti-Money LaunderingThe DetectX® Anti-Money Laundering brochure, to share with your team.
Download the brochureInsightThe essential guide to effective sanctions screeningWhat a sanctions screening programme needs to cover, and why the parties behind a company matter as much as the company itself.
Read the guideTransaction Filtering · DetectX®
Book a demonstration on your own payment flows: which transactions reach the filter, what the participants are checked against, and what an analyst sees when one is held.