In my discussions with issuer fraud teams, a successful 3-D Secure challenge no longer gets the trust it once did. A customer may have completed it while a fraudster coached them over the phone, and the team wants to assess that risk before letting the payment proceed. The Council's PSR compromise text agrees with them in Article 55(2): that a transaction was authenticated, strong customer authentication included, is in itself not necessarily sufficient to prove the payer authorised it.
"The only 100% effective challenge is a deny" is the bleak way to put it. Legitimate customers still need to pay, so the useful response is to assess what happened during the challenge and let that inform the decision about the payment, and if money is then lost and the customer disputes it, I'd want that assessment to be retrievable too.
That is why paragraph 1a of Article 83 in the same text matters to a card fraud team. It ties a refund to evidence of monitoring on the disputed transaction, so the practical question reaches beyond whether your systems monitored the payment to what your team could later put in front of the customer.
The proposed refund
The Council text would require the payer's provider to monitor before executing the payment and the payee's provider before making the funds available. Where a provider fails to monitor and the payer suffers financial damage, that provider bears liability. It then requires the payer's provider to refund the transaction if it does not give the payer evidence that both providers monitored it. The payer bears no financial consequences unless they acted fraudulently, and the burden of proving compliance sits with the provider concerned.
What strikes me about that refund sentence is that it asks nothing about authorisation. The route a customer uses under PSD2 turns on whether the payment was authorised and whether they were grossly negligent, and a passed challenge is the evidence you reach for first on both. Paragraph 1a opens a second route that turns only on whether you can show the monitoring ran, and the one thing that defeats it is the customer's own fraud.
For an issuer fraud team, I'd start with its own contribution to that evidence. A record of your assessment would answer your part of the question, while the text's requirement concerning both providers would remain, and how an issuer would evidence the acquirer's monitoring is a question the text leaves open.
The duty itself is not new, since RTS Article 2 has required monitoring since September 2019. What Article 83(1a) adds is the connection between evidence of monitoring and a refund, with the payer named as the recipient, and a description of how your fraud system works would not, by itself, show what happened on this payment.
What 3DS supplies
Article 83(1) says what the monitoring is for: supporting the application of strong customer authentication, exempting it on the Article 85(11) criteria, and preventing and detecting fraudulent transactions. As I read it, the risk assessment your ACS runs to choose between a frictionless outcome and a challenge is transaction monitoring in the article's own terms, under the first two of those purposes, and an assessment made after the challenge falls under the third.
Some of the inputs for that assessment already arrive through 3DS. In EMV 3DS 2.3.1.1, the Authentication Request, or AReq, carries the purchase amount and merchant name for payment authentication. The browser IP address is a browser-channel field, subject to regional or market restrictions, and in the app channel the deviceInfo field carries SDK device information on the leg from the Directory Server to the ACS.
Those data overlap some of the categories in Article 83(2), including transaction, session and device data, but the overlap is partial. Merchant name is not the unique payee identifier the provision names, and the issuer's own account history and its view of the customer's normal behaviour are separate inputs that the AReq cannot carry.
Receiving the data, performing the monitoring and producing evidence of it are three separate steps, and neither the AReq nor a successful challenge result establishes, on its own, that the Article 83 duties were met. The AReq also has a timing limit. The request that initiated an authentication cannot describe behaviour during the challenge that follows, so assessing that behaviour depends on observations made later in the flow.
After authentication can still be before execution
Consider a challenge completed much faster than the customer's usual pattern, or an active incoming phone call during the challenge where your implementation can observe it. Neither observation proves fraud. Article 83(2)(a) names the payer's environmental and behavioural characteristics in the normal use of their credentials as data the issuer may process for monitoring, and where those signals are available and lawful to use, I'd want them weighed in a secondary assessment alongside the transaction and what you already know about the customer.
A secondary assessment lets you reconsider the risk after the customer has responded, but for it to stop this payment it has to finish while you can still act on the result. Article 83(1a) sets the payer-side deadline at execution, and an assessment made after authentication falls before that. For a card payment, on my reading, the last point at which you can act is your authorisation response, which comes earlier still. A review after execution cannot perform the monitoring after the fact.
Article 83 does not prescribe a separate assessment after every challenge, or mandate either signal. My point is that if your fraud strategy includes one, the evidence you retrieve should include it, because the initial risk decision and the challenge result may omit the assessment that actually decided whether the payment went ahead.
The record your team can retrieve
Work backwards from a disputed payment that passed the challenge and then cost the customer money. Ask your team to retrieve the assessments performed on that payment, what each one weighed and when it ran, together with any action taken as a result, and where you reassessed the risk after the challenge, what that assessment considered and how it affected the decision.
The useful record connects the authentication to the payment and establishes the sequence through to execution. A score without the assessment it belongs to would be difficult to use in a customer response, and a reconstruction of what the system would normally do is weaker evidence than a record of what it did on the transaction being disputed.
Article 83 leaves the form of the evidence unspecified, and Article 89(1)(g) hands the EBA the technical requirements for monitoring. I'd distinguish the internal record needed to substantiate the assessments from the account you can give the customer: the provision does not expressly require handing over raw model scores or proprietary rules, and a readable account would still need evidence behind it.
The refund provision remains in a compromise text awaiting adoption, not applicable law. You can nevertheless test whether the record is usable with a case you have already handled. When the customer comes back, your team should be able to show the assessments behind the decision to let that payment proceed.