Instant payment schemes do not wait for a batch window. DetectX® IPTF takes the payment from your instant payment system over a REST API, checks it against the same sanctions and PEP lists as the rest of the platform, and answers OK or NOK: most transactions are processed within one second. Anything held arrives in the same AlertViewer as every other alert.
One Platform. Total Compliance.
One Platform. Total Compliance.
Instant Payment Transaction Filtering screens each instant payment as it is made, through a REST API, on servers built to keep running. It applies the same name checking and business rules as Transaction Filtering.
In and out through one interface. Your payment service calls DetectX® through a REST API as each payment is made, and gets the result back the same way. Alerts and configuration live in DetectX®.
Six steps, on every payment. Each instant payment is received, parsed and routed, scored twice and checked against your rules before the answer goes back. Most transactions are processed within one second.
The payment arrives through the REST API.
The message is parsed and forwarded to the processing node for the relevant list.
Worker services calculate a first similarity score.
Country, date of birth and other attributes refine it into the final similarity score.
A post service checks the payment against your business rules.
The answer goes back through the REST API: OK or NOK.
No single point of failure. Instant payments can’t wait, so the service runs as an active-active cluster: two or more application and processing servers working in parallel behind a load balancer.
No client datamart or Data Collection Module needed.
High availability needs at least twice the hardware of Transaction Filtering for the same workload.
Configure once, screen both channels. The instant service runs on its own databases, kept in step with Transaction Filtering. Rules, dictionaries and configuration synchronise both ways every couple of minutes, the White List and lists come from Transaction Filtering, and alerts flow back into DetectX®.
Rules and Dictionariesboth ways
Configurationboth ways
White Listfrom Transaction Filtering
Listsdownloaded by Transaction Filtering, imported here
Alertsfrom instant payments to DetectX®
One policy for every payment. Instant Payment Screening applies the same controls as Transaction Filtering. What changes is how a payment arrives and how fast the answer goes back.
Instant payments cannot wait. Screening cannot be skipped.
DetectX® Instant Payment Screening checks each payment inside your payment flow and answers in time for it to settle. It uses the same lists, rules and White List as Transaction Filtering, and runs without a single point of failure, so screening never has to step aside.
Your payment service calls DetectX® through a REST API as each payment is made, and gets the result back the same way.
Extraction and Transformation
payment: CHF 4,800.00
creditor: Castellan Advisory SARL
debtor: Lukas Vogelresult: hit
similarity: 94
alert: AL-ONLINE-00312749Example data. Field names illustrative.
A first similarity score is refined with country, date of birth and other attributes into the final score.
How a name is scoredInstant payments cannot wait, so the service runs across two or more application and processing servers behind a load balancer.
Name ScreeningIllustration. Availability is designed around continuous operation.
Rules, dictionaries and configuration are synchronised in both directions, and alerts flow back into DetectX®.
Business Rule EngineInstant Payment behaves like Transaction Filtering. The difference is how payments arrive.
Transaction FilteringInstant payment alerts are worked in AlertViewer with the same workflows, rights and audit trail as every other module.
WorkflowsMost instant screening runs on its own rules. DetectX® gives the same answer.
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 Instant Payment Screening 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: four steps, from an instant payment to a recorded decision.
Your instant payment system calls DetectX® while the payment waits. DetectX® answers OK or NOK, and a held payment reaches the same AlertViewer as every other alert. Every step is yours to drive.
Illustrative exampleInvented Names & Data
Start with Instant Payment. 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 Instant Payment Screening.
Instant payment screening is the check of an instant payment against sanctions lists, internal blacklists and a bank’s own payment rules while the payment waits, so the answer comes back before the scheme’s settlement deadline. DetectX® Instant Payment Screening is called by your instant payment system through a REST API, scores the counterparty, tests the payment against your business rules and returns OK or NOK. Most transactions are processed within one second, and anything that needs a decision becomes an alert in AlertViewer.
Most transactions are processed within one second; that is the figure in the operations documentation, not a contractual service level. The deadline itself is set by the scheme: for euro instant credit transfers, the payee’s PSP must make the funds available within 10 seconds of the payer’s PSP receiving the order, and if no confirmation arrives in that time the payer’s account is restored as if the transfer had not happened. How DetectX® is configured to behave near that limit is agreed with your team during integration.
Not against EU targeted financial sanctions. Regulation (EU) 2024/886 inserted Article 5d into the SEPA Regulation: PSPs offering instant credit transfers must check whether any of their own customers are subject to EU targeted financial restrictive measures, immediately after any new or amended designation and at least once every calendar day. During the transfer itself, neither PSP may additionally check the payer or payee against those measures. That limit does not cover other restrictive measures, measures not adopted under Article 215 TFEU, or EU anti-money laundering law, so non-EU lists, your own blacklists and your payment rules can still apply. PSPs had to comply with Article 5d by 9 January 2025. Source: Regulation (EU) 2024/886, EUR-Lex, last reviewed 26 October 2026.
Transaction Filtering screens standard payments from your core banking system and can take minutes; Instant Payment Screening answers each instant payment while it waits. Instant Payment Screening is called through a REST API, returns OK or NOK, runs on its own databases and runs as an active-active cluster. Rules, dictionaries and configuration are synchronised between the two every couple of minutes, so both apply the same policy.
Yes. The lists are downloaded by Transaction Filtering and imported into Instant Payment Screening, which keeps them up to date. Rules, dictionaries and configuration are synchronised in both directions, and the White List comes from Transaction Filtering, so a counterparty your analyst has already cleared is not held again just because the payment was instant.
The alert reaches AlertViewer and is worked there like any other. Alerts flow from Instant Payment Screening to DetectX® every couple of minutes and appear in the same working list, with the payment and what matched. Your analyst comments on, decides and closes it there.
Yes. Instant Payment Screening supports multitenancy: several tenants share one installation and one source of lists, while each keeps its own models and its own White List.
What a seconds-long settlement window does to screening, and how compliance teams balance speed against control.
Read the articleCase studyGenerali SwitzerlandTwo decades with Prospero, from Name Screening in 2007 to transaction filtering in 2024.
Read the case studyInsightSanctions screening explainedHow to screen against current sanctions requirements, manage false positives and choose the technology to do it.
Read the articleInstant Payment Screening
The useful conversation about instant payments starts with your scheme, your volumes and your deadline, not with a feature list. Tell us those and we will tell you what the architecture has to look like.