Fraud liability is the quietest line in a payments contract and the costliest and the most expensive one to get wrong. PSD3 moves it, and the direction is toward providers.

The regulatory backbone is set. PSD3 and the Payment Services Regulation govern how online card payments are authenticated, how SCA exemptions apply, how open banking performs and how fraud liability is allocated for the rest of the decade, as merchant-facing analysis of the framework describes. Authorised push payment fraud, social engineering and impersonation all rose significantly in the period that shaped the drafting.

Vladyslav Kolodistyi, who works on payments infrastructure at PayAdmit, thinks merchants read liability changes too narrowly.

"Everyone asks who pays after the fraud," says Vladyslav Kolodistyi. "The more useful question under PSD3 is what changes before it. Liability allocation under PSD3 is an incentive design, and payments teams that only model the loss miss what the regulation is trying to make them build."

Strong Customer Authentication still decides where the loss lands

The mechanism is unchanged and worth restating, because a great deal follows from it. Payments authenticated through 3D Secure 2 under SCA shift fraud chargeback liability from merchant to issuer. Payments processed under an SCA exemption do not. That single distinction is why SCA exemption strategy is a risk decision as much as a conversion one.

Vladyslav Kolodistyi frames the trade-off directly. "Claiming an SCA exemption buys conversion and keeps liability," he says. "Challenging under SCA costs conversion and moves liability. Payments teams make that trade thousands of times a day, usually without anyone having priced it deliberately."

PSD3 also shifts liability toward payments providers on impersonation fraud under defined conditions, alongside tightened payments fraud detection obligations and stronger transaction monitoring. The provisional agreement also brought SCA governance, non-smartphone authentication availability and fraud-data-sharing arrangements into scope, as legal analysis of the PSD3 and PSR package sets out.

Fraud data sharing deserves a note of its own. PSD3 and the PSR expand information exchange between payments providers, improving payments detection and creating a compliance workload. Firms joining a consortium need a compliance-grade data protection impact assessment, and Vladyslav Kolodistyi finds payments teams discover that requirement late.

"Fraud data sharing is one of the better ideas in PSD3," he says. "It is also the one that stalls in legal review when payment compliance work starts three months before a deadline instead of eighteen."

There is an operational consequence that follows directly from the liability rules. Because an authenticated payment under SCA shifts chargeback liability, some payments teams treat challenges as a risk-reduction default. Vladyslav Kolodistyi considers that a costly reflex under PSD3.

"Challenging every payment is not a compliance strategy," he says. "It is a conversion tax you chose to pay. The SCA framework exists so payments can be risk-assessed rather than uniformly challenged, and PSD3 keeps that framework intact for a reason."

The reverse error is equally common. Claiming every available SCA exemption maximises payments conversion and concentrates fraud liability on the merchant, which works until the loss rate moves. The payment compliance question is where the balance sits for a given portfolio, and it is a number rather than an opinion.

Payment compliance, loss modelling and the exposure nobody calculated

The practical work is quantification, and Vladyslav Kolodistyi finds it is rarely done before a regulation changes the answer.

Most payments teams can state their chargeback rate. Far fewer can state what share of payments fraud losses sit with the issuer because of SCA, and what share would move if exemption strategy changed. Without that split, compliance and liability changes cannot be modelled.

Four payments figures worth establishing before the rules apply:

1. Fraud loss on payments authenticated under SCA versus payments processed under exemption
2. The payments conversion cost of an SCA challenge, measured by issuer rather than blended
3. The fraud rate governing PSD3 transaction risk analysis eligibility, monitored continuously
4. Payments exposure to impersonation fraud, since compliance liability moves furthest there, since that is where PSD3 moves liability furthest

The second figure is the one that changes decisions. If an SCA challenge costs three points of payments conversion and saves a small fraction of a point in fraud, the exemption is obviously right. If the numbers invert, so does the strategy. Vladyslav Kolodistyi points out that most payments teams have never calculated either side.

"You cannot optimise a trade you have not priced," he says. "PSD3 does not change that. It changes the price, which is a good reason to work out what the price is now."

There is a vendor dimension. Under PSD3, delegated SCA counts as outsourcing, so a payments provider's fraud and compliance performance and resilience posture become the merchant's compliance exposure. Contracts predating the PSD3 agreement rarely carry the audit rights and exit provisions the regime expects.

Provisioning follows the same logic. As liability moves toward providers, pricing will follow, and merchants should expect PSD3 fraud costs to appear in payments fees rather than in chargeback lines. Vladyslav Kolodistyi expects that repricing to be uneven and slow to become visible.

"Liability does not disappear," he says. "It gets priced into payments compliance. Payments teams celebrating a liability shift should watch their provider's next commercial proposal carefully, because PSD3 changed their cost base too."

Jurisdiction complicates the picture further. The United Kingdom is not adopting PSD3 and has its own approach to fraud reimbursement, so a merchant operating in both markets faces different payments liability allocations for functionally identical payments. Building the payments stack so SCA rules are configurable per market is the only sustainable answer.

Preparation does not require the final text. Splitting fraud losses by SCA status, measuring challenge cost by issuer, reviewing delegated SCA arrangements and starting the data protection work for fraud sharing are all available now, and each improves payments outcomes regardless of when PSD3 compliance bites.

Monitoring obligations tighten under PSD3 in ways that touch loss modelling directly. Transaction monitoring becomes a firmer expectation, fraud reporting becomes stricter, and the fraud rate governing transaction risk analysis eligibility has to be tracked continuously rather than reviewed periodically. A payments platform discovering its fraud rate quarterly cannot manage SCA exemption eligibility at all.

Vladyslav Kolodistyi treats continuous fraud rate monitoring as the single highest-value PSD3 preparation task for most merchants, because it is simultaneously a compliance requirement and the input that governs conversion.

"Your fraud rate is now a conversion parameter," he says. "Under PSD3 it decides how many payments you may exempt from SCA. Payments teams that monitor it monthly are steering with a delay they cannot afford."

Insurance and provisioning follow the same modelling. Merchants that can split fraud losses by SCA authentication status can price their own exposure under PSD3 and negotiate with providers from evidence rather than assertion. Those that cannot will accept whatever compliance and pricing position their payments provider proposes.

He finds that asymmetry decides most commercial payments conversations. "Your payments provider has the data," he says. "If you cannot reproduce it, you are negotiating PSD3 liability terms blind, and payment compliance departments are not usually equipped to argue about fraud economics."

Chargeback operations feel the change last and hardest. If PSD3 moves a category of fraud liability toward providers, the representment work that payments teams built around the old allocation stops matching reality, and disputes get argued on the wrong grounds. He recommends reviewing dispute templates against the new SCA and liability position rather than assuming the existing ones still apply.

"Nobody rewrites representment templates for a compliance change," he says. "Then the rules land, the payments team keeps citing the old liability basis, and win rates fall for reasons nobody connects to the regulation."

Governance closes the loop. Fraud liability under PSD3 is a board-level exposure rather than an operational detail, and the payment compliance function needs a defined view on how much fraud loss the business is willing to retain in exchange for payments conversion. That number rarely exists in writing.

"Somebody is making that trade every day inside your payments routing," says Vladyslav Kolodistyi. "Usually it is a default nobody chose. Under PSD3 the compliance consequence of that default is larger, which is a good reason to write the risk appetite down."

The framing Vladyslav Kolodistyi returns to is consistent. PSD3 will be described as a compliance programme, and that description will cost people money. It is a payments product programme with a legal deadline, and liability is one of the levers it hands to teams willing to measure. Further commentary from Vladyslav Kolodistyi on payment compliance and payments fraud is published through his LinkedIn profile.