Instant Payments Sanctions Screening
Article 5d did not ban sanctions screening on the instant rail. It moved the object of the screening from the transaction to the customer base, prohibited one specific check in one specific window between two specific parties, and carved out three categories expressly. This walks the pre-2025 screening stack component by component and states, for each one, what replaces it and which control it was carrying.
19 min read
28 views
Key takeaways: instant payments sanctions screening 5
What Article 5d actually prohibits, the four limits written into that prohibition and which controls it leaves completely untouched.
- The prohibition is four-cornered: during execution only, the two PSPs involved in that transfer only, targeted financial restrictive measures only, and only screening additional to the daily verifications. It is not a ban on transaction screening Each of the four limits comes from a separate phrase in the same sentence, so a check running before a payment order exists or well after settlement sits outside the prohibition entirely. Reading the sentence as an outright ban on sanctions screening overstates what the text says, since three of the four limits narrow who and what it actually reaches.
- A screening hold has nowhere to live inside a 10-second ceiling that starts at time of receipt and ends in a mandatory restore of the payer's account The payer's PSP must verify and send the payment onward immediately, and the payee's PSP then has ten seconds to confirm, so a hold that pends a transaction for review has no state to occupy in that sequence. Where no confirmation arrives in time, the payer's account must be restored immediately rather than left pending.
- The daily list run is a floor, not a schedule. Two further triggers fire immediately on entry into force of a new measure and of any amendment to one A PSP running the verification once a day meets the stated minimum and nothing beyond it, since the wording sets a floor rather than a fixed schedule. The other two triggers are tied to the moment a measure or an amendment enters into force rather than to a calendar cadence.
- The prohibition covers instant credit transfers in euro, because the regulation it lives in reaches only euro-denominated transactions. Article 5d itself says nothing about currency The currency limit comes from the scope article of the regulation the prohibition lives in rather than from the prohibition's own wording, so reading Article 5d in isolation will not show it. The article treats this reading as its own inference rather than as a settled finding.
- Real time AML transaction monitoring is untouched, and so are non-targeted measures under Article 215 TFEU and restrictive measures adopted outside it The prohibition carves out three separate bodies of obligation by name, so anti money laundering monitoring, other restrictive measures under Article 215 TFEU and restrictive measures adopted outside it all keep working exactly as before. A cleanup that decommissions the old screening service without separating these controls risks removing something nobody asked to remove.
Instant payments sanctions screening did not stop on 9 January 2025, it changed object. If you own the screening stack at a payment service provider, you have most likely been handed a summary saying the check is banned on the instant rail, and what a design review needs from you is narrower than that: which check, inside which window, between which two parties. Sections below walk the stack as it stood before 2025 component by component, ordered by blast radius, opening with the piece whose removal disturbs the most system and closing with the piece that did not move at all.
In short: Reg (EU) 2024/886, Art 1(2), inserting Art 5d into Reg (EU) No 260/2012, moved the object of the screening obligation from the transaction to the customer base, and Art 5d(1) now requires a PSP offering instant credit transfers to verify its own payment service users immediately after new targeted financial restrictive measures enter into force, immediately after any amendment to them enters into force and at least once every calendar day. The Art 5d(2) prohibition carries four limits on the face of the text: it bites only during the execution of an instant credit transfer, only on the payer's PSP and the payee's PSP involved in that transfer, only as to targeted financial restrictive measures and only as to screening additional to those Art 5d(1) verifications. Its second subparagraph then carves out three things expressly, being restrictive measures other than targeted financial ones adopted under Article 215 TFEU, restrictive measures not adopted under Article 215 TFEU and Union law on the prevention of money laundering and terrorist financing, so real time AML transaction monitoring is untouched. The prohibition covers instant credit transfers in euro, because the regulation it lives in reaches only euro denominated transactions, and Art 5d itself carries no currency words at all. Art 5d(3) sets one compliance date, 9 January 2025, for every PSP, with no euro and non euro split.
The synchronous screening call in the payment execution path
Every euro instant transfer used to pass through a blocking call into a screening service: payer and payee checked against targeted financial lists, the message held until the call came back clear. Nothing takes its place inside the path. Reg (EU) 2024/886, Art 1(2), inserting Art 5d(2) into Reg (EU) No 260/2012, removes it in one sentence:
During the execution of an instant credit transfer, the payer's PSP and the payee's PSP involved in the execution of that instant credit transfer shall not verify whether the payer or the payee whose payment accounts are used for the execution of that instant credit transfer are persons or entities subject to targeted financial restrictive measures in addition to carrying out verifications under paragraph 1 of this Article.
That text appears character identically in the amending instrument and in Reg (EU) No 260/2012 as consolidated in force from 8 April 2024, which is where the operative version now lives.
Four limits, in the words that create them
Read the sentence as four separate restrictions rather than as one ban. Limit one is temporal. "During the execution of an instant credit transfer" is the window, so a check running before a payment order exists, or after settlement, sits outside the sentence entirely.
Limit two is the addressee. Only "the payer's PSP and the payee's PSP involved in the execution of that instant credit transfer" are named. Intermediary PSPs, payment scheme operators and clearing mechanisms are neither brought in nor kept out by this text, and nothing in the sources behind this article speaks to them, so the honest answer is that Art 5d(2) names two actors and stops there.
Limit three is subject matter. Only verification against "targeted financial restrictive measures" is caught, and the second subparagraph then confirms that narrowness by carving out three neighbouring bodies of obligation. Limit four is the comparator. What the text forbids is verification "in addition to carrying out verifications under paragraph 1 of this Article", so the prohibition presupposes the Art 5d(1) duty rather than displacing it.
By its own terms the sentence reaches only the execution of an instant credit transfer, which is the whole of what can safely be said about its edges. Within those edges it is not advice. A PSP still holding a synchronous list call inside the instant path is doing a thing the operative text says it shall not do.
One date, for everybody
Art 5d(3) reads "PSPs shall comply with this Article by 9 January 2025." One date, every PSP, no euro and non euro split. Articles 5a, 5b and 5c each set two dates or more, so a team pattern matching those onto Art 5d will produce a date that does not exist. Corroboration sits in the euro adoption bridging rule at Art 16(9), added by Reg (EU) 2024/886, Art 1(5), which lists Articles 5a, 5b and 5c and omits Art 5d: there is no split for it to bridge.
The control that depended on the in path call was catching a designation at the moment of transfer. That control is gone from the payment path and has to be rebuilt against the customer base, which is what the rest of this article walks through.
The hold, pend and reject disposition on the payment
Suppose the prohibition did not exist. A screening hold would still have nowhere to live, because the execution machinery leaves it no slack. That machinery is quoted below in the order a payment meets it.
The sequence a payment has to fit inside
Under Art 5a(4)(b) the payer's PSP must, "immediately after the time of receipt of a payment order for an instant credit transfer", verify that the processing conditions are met and the funds available, reserve or debit the amount, and "immediately send the payment transaction to the payee's PSP". Art 5a(4)(c) then gives the payee's PSP "within 10 seconds of the time of receipt of the payment order for an instant credit transfer by the payer's PSP" to make the amount available and confirm completion. Art 5a(4)(e) requires the payer to be told the outcome "free of charge", either on that confirmation or once 10 seconds pass without one. Where no confirmation arrives, Art 5a(5) says the payer's PSP "shall immediately restore the payment account of the payer to the state in which it would have been had the transaction". Our extraction of that provision stops there, its closing words are not on record and they are not supplied here.
Notice what binds the payer side leg. Art 5a(4)(b) says "immediately", which is not a number, and a number would be easier to design against. A hold that pends a payment for analyst review has no state to occupy in that sequence: funds are reserved or debited in the same breath as the onward send, and silence at 10 seconds is defined as failure with a mandatory restore attached rather than as a decision still pending. Which is why a transaction level control that sits comfortably in a batch window behaves differently here, a boundary this rail shares with crypto transaction monitoring integration.
Where the clock starts
Engineers look for slack at the start of the clock, so Art 5a(3) is worth reading in full. Its general rule, in the first subparagraph, sets time of receipt as "the moment it has been received by the payer's PSP, regardless of the hour or calendar day", disapplying Article 78(1), second subparagraph, of Directive (EU) 2015/2366, the provision that would otherwise push a late order into the next business day. Its second subparagraph handles scheduled instructions: where payer and PSP agree that execution is to happen at a specific time, the time of receipt "shall be deemed to be the agreed time, regardless of the hour or calendar day".
A third subparagraph then opens "By way of derogation from the first and second subparagraphs of this paragraph, the time of receipt of the payment order for an instant credit transfer shall be:" and supplies three carve outs. For a non electronic order it is "the moment when the payer's PSP has introduced the payment order information into its internal system". An individual order coming out of a package takes "the moment when the ensuing payment transaction has been unpacked by the payer's PSP" instead. For an order from an account not denominated in euro it is "the moment when the amount of the payment transaction has been converted into euro". None of those branches buys screening time. Two of them start the clock later than the customer's own action, and both carry a promptness duty in the same sentence that grants them.
What replaces the disposition
An account state, set before any payment exists, is what replaces it. Recital 26 states the purpose of verifying immediately on a new listing: "To prevent the initiation of instant credit transfers from payment accounts belonging to persons or entities subject to targeted financial restrictive measures and to immediately freeze funds sent to such payment accounts, PSPs should carry out verifications of their PSUs immediately following the entry into force of a new targeted financial restrictive measure." Both extractions of recital 26 behind this article stop before its closing words.
Read that carefully, because it is a recital stating a purpose. Art 5d imposes no freeze duty in the evidence base behind this article. Operative freeze obligations live in the restrictive measures instruments themselves, none of which we have sourced here, so what an account state change must actually do to funds is a question for your own sanctions counsel and not one this article answers.
Alert queues and the hit review desk
Volume was the legislator's stated reason, and recital 25 puts it in qualitative terms only. Screening the payer and the payee on each credit transfer, it records, "leads to a very high number of credit transfers being flagged as potentially involving persons or entities subject to targeted financial restrictive measures", while "the large majority of such flagged transactions turn out, after verification, not to involve any of the persons or entities subject to targeted financial restrictive measures". Given the nature of instant credit transfers "it is impossible for PSPs to verify, within the required short time limit, those flagged transactions and, as a result, they are rejected". Its conclusion is that PSPs "should no longer apply transaction-based screening in that specific context".
No rate, ratio or per day figure appears anywhere in the material behind this article, and none is estimated here. The whole of what the legislator committed to in writing is "a very high number" and "the large majority".
The operating model that follows is ours rather than the regulation's. One queue becomes two populations, both reviewed off the payment clock: a base population verified on the daily cadence, and an event population raised whenever a listing change fires the immediate trigger. Neither is bounded by 10 seconds, which is the point of the exercise. Analyst adjudication that used to sit between a hit and the movement of money now sits between a hit and whatever your account state change is designed to do. Sizing that work means sizing the whole customer base, because Art 5a(1) requires every payment account reachable for credit transfers to be reachable for instant credit transfers "24 hours a day and on any calendar day".
Matching logic pointed at the payment message
Article 5d announces the change in its own heading, which reads in full: "Screening of PSUs by PSPs that offer instant credit transfers to verify whether a PSU is a person or entity subject to targeted financial restrictive measures". Payment service users, not payments. Art 5d(1) then states the duty in one line: "PSPs offering instant credit transfers shall verify whether any of their PSUs are persons or entities subject to targeted financial restrictive measures."
The engine's input changes because the object changed. A payment message carries whatever the originating channel put into it, shaped by a scheme and bounded by a field length. A PSU record is a different data shape: identifiers your own onboarding collected rather than whatever a message happened to carry, on a refresh cadence owned by a different team. Ownership moves with it, since the record sits with customer data rather than with payments. Name matching quality was the control resting on the old input, and it travels to the new one. Budgeting that work is closer to list screening of a customer base than to the per payment economics in crypto AML screening cost, and the two should not be modelled together.
The nightly list refresh job
Housekeeping became an operative duty. Art 5d(1), second subparagraph, sets three triggers in a single sentence: PSPs "shall carry out such verifications immediately after the entry into force of any new targeted financial restrictive measures, and immediately after the entry into force of any amendments to such targeted financial restrictive measures, and at least once every calendar day".
Two phrases in that sentence do the work. The words "at least" make the daily run a floor rather than a schedule, so a PSP running once a day has met the minimum and nothing beyond it. The word "immediately" attaches to entry into force twice over, once for a new measure and once for an amendment to an existing one, and immediacy is not a cadence you can express in a crontab.
One engineering consequence here is ours rather than the regulation's. Entry into force is an Official Journal event, and a vendor list feed arriving some hours afterwards does not move the duty. Nothing in the text we hold describes how a PSP learns that a measure has entered into force, which makes the gap between publication and feed arrival a design problem you own. What was a refresh job becomes an event driven pipeline with a daily floor underneath it, and list currency stops being a metric only the screening team ever saw.
Screening evidence records written per transaction
Supervisors used to be shown an artefact per payment: a screening decision bound to a message id, with a list version and a disposition beside it. On the euro instant rail that artefact no longer has a source. What exists instead is an artefact per run and per population, recording which population was verified, against which list version, at what time and on which of the three triggers.
The penalty regime inserted at the same time sets the stakes. Art 11(1a) of Reg (EU) No 260/2012, inserted by Reg (EU) 2024/886, Art 1(3), required Member States to "lay down rules on the penalties applicable to infringements of Articles 5a to 5d" by 9 April 2025, and those penalties must be effective, proportionate and dissuasive. Art 11(1b) then singles out Art 5d, and its point (a) requires "in the case of a legal person, maximum administrative fines of at least 10 % of the total".
Our extraction of point (a) stops at "of the total". Whatever noun the percentage attaches to was never surfaced, so this article does not name one and neither should a slide built from it. Point (b), which presumably covers natural persons, is unread here. Safely on record: a penalty floor for Art 5d exists in operative text, it is expressed as a percentage of at least 10 and it bites on legal persons.
The scope table that said screen every flow
Smallest change in code, most frequently misstated. Four of the prohibition's coordinates are visible in the sentence itself and were taken apart above. A fifth is not in Art 5d at all.
Why the euro limit is not in Article 5d
The prohibition covers instant credit transfers in euro, because the regulation it lives in reaches only euro denominated transactions. Four steps make that chain and none of them is Art 5d. Art 1(1) of Reg (EU) No 260/2012 is the scope article: "This Regulation lays down rules for credit transfer and direct debit transactions denominated in euro within the Union where both the payer's payment service provider and the payee's payment service provider are located in the Union, or where the sole payment service provider (PSP) involved in the payment transaction is located in the Union." In the consolidated text that article stands under the base text marker, meaning it reads as enacted in 2012. Reg (EU) 2024/886, Art 1, amends Reg (EU) No 260/2012 at exactly five points, being Article 2, the insertion of Articles 5a to 5d, Article 11, Article 15 and Article 16, and the scope article is not among them. Nor does the defined term carry the limitation: an "instant credit transfer" is defined at Art 2, point (1a), as "a credit transfer which is executed immediately, 24 hours a day and on any calendar day". And when the same legislator imported that same definition into Regulation (EU) 2021/1230, whose own scope article supplies no currency limit, it bolted one on in terms, defining the imported term as an instant credit transfer "that is in euro and cross-border".
One caveat travels with the conclusion. The words "in euro" are genuinely absent from Art 5d(2), and anyone reading Art 5d alone will not see the limitation. That absence is real, and it is evidence of nothing wider: it is the ordinary economy of a provision sitting inside an instrument whose scope article has already done the work.
An extension of the same reasoning, marked as ours. Art 5c, the verification of payee article, likewise speaks of credit transfers without a currency word, and Art 1(1) plainly reaches it too. That reading has not been adjudicated against the sources behind this article, so treat it as our inference and not as a finding.
What the old scope table gave you was a statement of which flows your screening obligation covered. Rebuilding it means a per rail assertion rather than a global switch, because the in path check comes out of the euro instant rail and the assertion has to say which rails still run one.
The controls that did not move
Zero blast radius by construction, which is why it comes last, and it is the section a team is likeliest to break by accident during cleanup. Art 5d(2), second subparagraph, is express:
The first subparagraph of this paragraph is without prejudice to actions taken by PSPs in order to comply with restrictive measures, other than targeted financial restrictive measures, adopted in accordance with Article 215 TFEU, with restrictive measures that are not adopted in accordance with Article 215 TFEU, or with Union law on the prevention of money laundering and terrorist financing.
Three carve outs sit in that sentence and they are worth counting out. Restrictive measures other than targeted financial ones adopted under Article 215 TFEU are the first. Restrictive measures not adopted under Article 215 TFEU at all are the second. Union law on the prevention of money laundering and terrorist financing is the third. Real time AML transaction monitoring is untouched.
That is a fence rather than a nuance. Rule logic, thresholds and the whole real time monitoring path keep working as before, and tuning them is a separate discipline on a separate instrument, as in crypto AML transaction monitoring rule tuning. Sanctions screening under Art 5d has a different object, a different trigger set and a different architecture. A cleanup that decommissions an in path service without separating the two removes AML controls nobody asked you to remove.
Evidence a rebuilt stack should produce on demand
Everything in this section is our engineering view rather than a requirement of any instrument, and every regulatory statement behind it is cited in the sections above. Four artefacts are worth being able to produce without opening a ticket.
First, the population verified per run, with its list version, its timestamp and which of the three triggers fired it, because that is now the unit a supervisor can be shown. Second, the latency of the daily run measured against the calendar day boundary rather than against a rolling 24 hours, since the duty is expressed per calendar day. Third, the lag through the event pipeline from entry into force to completed verification, which is the number that stands in for immediacy when somebody asks what "immediately" meant in practice on a given day. Fourth, a scope assertion naming the rails the in path check came out of and the rails it still runs on, held as a tested statement rather than as a slide.
One observation comes from our own delivery record and is offered as engineering experience, nothing more. Across 41 Sev-1 and Sev-2 incidents tracked over 9 products between 2023 and 2026, third party services, APIs, blockchain RPC and identity providers accounted for 20 per cent of primary incident causes, the third largest class. Taking a third party call out of a path that carries a 10 second ceiling is therefore a reliability change as much as a compliance one, and the runs replacing it inherit that same dependency on a schedule where a slow answer is survivable. Where this turns into a build, it is compliance and RegTech solutions work rather than a policy document.
How Pharos Production helps
Pharos Production rebuilds the screening stack around the object the regulation actually names, starting with the PSU record because that is where the duty now sits. In practice that means an event driven verification pipeline whose trigger is a legal event rather than a vendor feed, a daily floor underneath it with a latency budget of its own, evidence written per run and per population instead of per message, and a scope assertion saying out loud which rails carry an in path check and which do not. On the payment path we treat the 10 second ceiling and the mandatory restore as test cases rather than as configuration. This is payment solutions development on a rail where the compliance design and the latency design are one design.
Sources: Regulation (EU) 2024/886 as published (CELEX 32024R0886), for recitals 25 and 26 and for its Article 1, points (1) to (5). Regulation (EU) No 260/2012 in its consolidated version in force from 8 April 2024 (CELEX 02012R0260-20240408), for Article 1(1), Article 2 point (1a), Article 5a(1), Article 5a(3), Article 5a(4), Article 5a(5), Article 5d(1) to (3), Article 11(1a) and 11(1b) and Article 16(9). The operative text of Article 5d lives in that consolidated instrument rather than in the amending one, and every provision cited here entered it through Reg (EU) 2024/886, Art 1(2), except Article 11 through Art 1(3) and Article 16(9) through Art 1(5). Regulation (EU) 2021/1230, Article 3(5), second subparagraph, as added by Reg (EU) 2024/886, Art 2(1), for the drafting practice contrast. Two quotations stop where our sources stop and are not completed: Article 5a(5) at "had the transaction" and Article 11(1b)(a) at "of the total". Recital 26 is quoted from extractions that do not reach its closing words, and Article 11(1b)(b) was not read. The blast radius ordering, the two population operating model, the event pipeline framing, the entry into force reasoning, the evidence set and the currency scope reading of Article 5c are ours. Our incident figures are our own delivery record, not market or industry data. This is engineering guidance, not legal advice.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 7
No matches
Try a different keyword, change the topic or clear filters
-
No, and the circulating version of that claim is overbroad. The prohibition has four limits on the face of the text: it bites only during execution of an instant credit transfer, only on the payer's PSP and the payee's PSP involved in that transfer, only as to targeted financial restrictive measures, and only as to screening additional to the daily verifications required by Art 5d(1).
-
The customer base. A PSP offering instant credit transfers must verify whether any of its PSUs are persons or entities subject to targeted financial restrictive measures, immediately after the entry into force of any new such measures, immediately after the entry into force of any amendments to them, and at least once every calendar day.
The daily run is a floor.
-
No. The prohibition is expressly without prejudice to actions taken to comply with Union law on the prevention of money laundering and terrorist financing, alongside two further carve-outs for restrictive measures other than targeted financial ones adopted under Article 215 TFEU and for restrictive measures not adopted under Article 215 TFEU.
-
It covers instant credit transfers in euro, because the regulation it lives in reaches only euro-denominated transactions. The words "in euro" are genuinely absent from Art 5d(2), and the limitation comes from the scope article of Regulation (EU) No 260/2012, which Regulation (EU) 2024/886 did not amend.
-
9 January 2025, for all PSPs, with no euro area and non-euro split. Articles 5a, 5b and 5c each set two dates or more, so a team pattern matching those onto Article 5d will produce a date that does not exist.
-
Because the execution machinery leaves no room for one. The payer's PSP must verify and send onward immediately after time of receipt, the payee's PSP has 10 seconds from that same moment to make funds available and confirm, and where no confirmation arrives the payer's account must be restored immediately.
The legislator's own reasoning in recital 25 is that flagged transfers cannot be verified inside that window and are therefore rejected.
-
Member States had to lay down the rules by 9 April 2025. For a legal person the operative text requires maximum administrative fines of at least 10 per cent of the total, and the noun the percentage attaches to was not surfaced in the text we retrieved, so we do not state one.
The provision covering natural persons is unread.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
