Payment screening solutions that sit beside the filter you already run

Payment screening solutions are the systems a bank uses to check wires, ACH and instant payments against sanctions lists before they move. There are two layers. The first is the filter, the interdiction software that screens every payment and stops potential matches, which a bank sending international payments typically already runs. The second, newer layer works on what the filter has stopped: it reads each held payment, gathers the evidence a person needs and recommends a decision. Adding that second layer does not require replacing the first. Botminds' Payment Sanctions Screening is built as that second layer: seven agents on the held queue, the filter, its threshold and the payments hub unchanged, and the analyst and Sanctions Officer deciding as before.

What payment screening solutions do, and which part is new

The filter's job has not changed in decades: compare the parties, banks, places and words in each payment with the lists, and stop anything close enough to need a look. OFAC's FAQs on choosing software, written in 2015, describe a market of many packages that differ widely in cost and capability, and leave the choice to the bank and its regulator. What has changed is the volume and speed of payments, the richness of ISO 20022 data and the expectation that every decision on a stopped payment can be explained to an examiner.

The new part is the work between the stop and the decision. A filter produces a score and a matched string; a person needs to know which field the words sit in, which list entry and version they matched, whether an identifier rules the match out, what the bank decided last time, and what the customer normally does. OFAC has signalled its openness to tools for that work: it "is aware of artificial intelligence tools and other innovative compliance solutions, such as those that leverage information sharing mechanisms across financial institutions, which may enhance sanctions screening functions and reduce false positives", and "Where appropriate, based on an institution's assessment of risk, OFAC encourages the use of such tools" (OFAC, Sanctions Compliance Guidance for Instant Payment Systems, 2022).

Do I need to replace my payment filter to add AI?

No, and there are good reasons not to. The filter's configuration, its lists, its threshold and its test history are what examiners and internal audit know. The Wolfsberg Group expects banks "to document how their screening systems are configured in order to demonstrate that the configuration is reasonably expected to detect and manage the specific sanctions risks to which the FI is exposed and, importantly, to ensure transparency of any system limitations or risk based decisions which the screening controls are not designed to detect" (Wolfsberg Guidance on Sanctions Screening, 2019). Replacing the filter means rebuilding and re-proving all of that.

Adding a layer beside it changes much less. In Payment Sanctions Screening the filter's matching threshold is shown to the agents as read-only, set at 85 on the sample bank's desk and owned by the screening service. The agents may propose tuning with evidence; they never change it. Everything the filter stops still stops, and every decision is still made by a person.

The filter decides what stops. People decide what moves. The new layer only changes how long the space between them takes, and how well it is documented.

How do agents connect to the payments hub?

Through the held queue, in both directions. The payments hub passes each held payment with its full message; the screening service passes the hit, the words, the field, the list entry, its version and the score. The agents read, and the analyst's release or return goes back to the hub, which sends the payment on or returns it. On the sample wire, the analyst released at 10:18:06 AM and the hub sent the payment on at 10:18:08.

What about Fedwire's ISO 20022 format and IAT addenda?

The agents read the formats the hub holds: ISO 20022 pacs.008 and pacs.009, SWIFT MT, Nacha IAT entries with their addenda, and RTP and FedNow messages, each unfolded into plain fields with its path, and the raw message one click away. Fedwire moved to ISO 20022 on July 14, 2025, so a U.S. bank's held wires now arrive in the richer format whether or not its filter was retuned for it. Which fields matter for screening, and where hits and their evidence sit in a pacs.008, is the subject of ISO 20022 sanctions screening, field by field.

IAT entries bring their own detail: parties and addresses in addenda records, batches where one hit should not hold the rest, and incomplete originator data. On the sample bank's desk, the Travel Rule checker reads originator and beneficiary data on transfers of $3,000 or more, fills outgoing gaps from the bank's own records and drafts requests to sending banks for incoming ones, which an analyst sends.

Who owns the hold decision in the new setup?

The same people as before, with their duties written into the system. On the sample bank's desk, analysts release as the maker, propose rejects and blocks, and release groups of up to 25 lookalike hits. The Sanctions Officer approves or returns every reject and block, co-signs larger group releases and signs the OFAC reports. The wire operations manager reassigns and escalates but never decides a hit. The Head of Sanctions approves settings and standing rules; the administrator only proposes them; internal audit reads and exports and changes nothing.

Two rules keep the agents in their lane. No agent releases, rejects, blocks, files or approves anything. And a standing "good-guy" rule, which the agents may propose after three like releases, takes effect only when the Sanctions Officer approves it, expires after 12 months and is suspended the moment its list entry changes.

The decision stays with the officer: a block with its evidence and consequences

What examiners will ask about the new layer

They will ask how its rules are governed, how it is tested and whether it can be explained. OFAC's 2026 settlement with Bank of America makes the first point for any screening logic: OFAC expects alert parameters and rules to be set by risk, supervised, audited and tested, so that one mistake cannot multiply (OFAC, Bank of America, October 2026). That case involved an alert suppression rule, taken apart in OFAC false positive procedures; a layer that remembers earlier decisions has to show it never reuses one silently.

On models, the supervisory position is still forming. The Federal Reserve's April 2026 model risk guidance, SR 26-2, leaves generative and agentic AI outside its scope, while telling banks that their own risk management and governance must still decide the controls for any tool it does not cover (Federal Reserve, SR 26-2; what that means for an alert queue is worked through in AI for sanctions screening). The Wolfsberg Group's principles fill some of the gap: test before go-live that the results will be fair, effective and explainable, then keep checking after go-live that performance holds steady (Wolfsberg Principles for Using AI and ML in Financial Crime Compliance, 2022). For a held-payment layer the second test is concrete: the share of its proposals the analysts overturn, month by month, should not drift.

The examiner's questions about the filter do not go away either. The FFIEC still treats a flood of false hits as a sign that the interdiction program itself needs review, and expects what analysts learn to flow back: a name variant of an OFAC target that turns up in review belongs in the filter (FFIEC BSA/AML Examination Manual, OFAC). A layer beside the filter should make both easier, by showing which hits recur and which names deserve adding, without changing the filter itself.

An examiner's view: every agent step and human decision, with versions

Where this approach fits and where it does not

It fits a U.S. bank with a working filter and a held queue that is busy, slow or hard to explain: international wires, IAT and instant payments, hits on vessels, banks and free text that need lookups, and an examiner asking why payments were released. The U.S. Treasury's 2024 review found AI already in common use for sanctions and anti-money-laundering work, from sifting large data sets to flagging unusual activity and verifying identities (U.S. Treasury, Artificial Intelligence in Financial Services, December 2024); the held queue is one of the clearest places for it.

It does not fit everywhere, and a buyer should know where. If the filter misses true matches, fix the filter first: a layer that works on stopped payments cannot see payments that were never stopped, and a replay will show which problem you have. A bank with very low volumes may be better served by manual filtering, which the FFIEC accepts for lower-risk banks. Customer onboarding screening and transaction monitoring are different controls with their own queues. And for euro instant payments between EU banks, the EU's Instant Payments Regulation replaces payment screening with daily client screening, so there is no held instant payment to work on.

What is the integration timeline?

It depends on the connections, not on the agents, so it is worth sequencing honestly rather than promising a date. Start with a run on a sample of your own held payments, against your own list versions and earlier decisions; it answers whether the recommendations are worth having before any integration work. Replaying last quarter's held payments sets out how. Then connect read-only: held payments and hits in, recommendations visible to analysts beside the existing queue. Only then route decisions through it, with settings, reason codes, clocks and roles agreed and approved by the Head of Sanctions.

Each step can be reversed without touching the filter, which is the practical advantage of integrating rather than replacing. The hold clocks, escalation points and co-sign thresholds become settings with versions, and the reasons for them belong in the bank's own documentation; what each minute of a hold costs is worked through in pricing each minute a payment waits.

Questions to ask payment screening solutions vendors

The full product, with every screen on the sample bank's desk, is on the Payment Sanctions Screening page.

Questions people ask

Can it work with my core banking system and my screening vendor?

It is designed to: it reads the customer file from the core banking system read-only and takes the hit from the screening service as it is, without changing the vendor's lists or threshold. The connections that carry decisions, to the payments hub and the general ledger, carry only actions a person has approved.

What is the difference between a payment screening solution and transaction monitoring software?

Payment screening checks each payment against sanctions lists before it moves and holds potential matches for a decision. Transaction monitoring looks back across activity for suspicious patterns and leads to investigations and suspicious activity reports. They use different data, queues and deadlines.

Do agents make the filter's false positives go away?

No. The filter still stops what it stops, at its own threshold. The agents make each stopped payment faster and better documented to decide, group lookalike hits after a list update, and propose standing rules or filter tuning for people to approve, with evidence.

Is agentic AI covered by model risk guidance?

The Federal Reserve's SR 26-2 of April 2026 says generative and agentic AI models are not within its scope, but that a bank's risk management and governance practices should still guide appropriate controls. Banks should expect examiners to ask how such tools are tested, monitored and governed.

Does the bank still file its own OFAC reports?

Yes. The agents draft blocked and rejected reports with the evidence attached; the Sanctions Officer signs and files them through OFAC's reporting system within the 10-business-day deadline. Filing confirmations come back onto the same trail.

How do we start without a long project?

With a run on a sample of your own held payments, against your own list versions and earlier decisions. It shows, before any integration, whether the recommendations and their evidence would have helped your analysts.