A Payments Processor Just Asked How Your AI Fraud Model Explains a Transaction Decline: Answering the Article 13 Transparency Section
A payments processor or bank just sent you a vendor questionnaire. Section 3 is titled something like Transparency and Explainability. One of the questions reads:
"How does your AI system communicate the reasons for a transaction decline to the merchant, cardholder, or payment institution?"
You're the CTO of a fintech company — transaction fraud scoring, real-time payment risk assessment, card-not-present fraud detection. You're staring at that question wondering where to start.
This is the Article 13 question — and it's not about writing long legal text. It's about showing your buyer that your system's decisions are intelligible to the humans who need to act on them.
Here's exactly what Article 13 of the EU AI Act requires, what your buyer is actually looking for, and how to answer it precisely.
What Article 13 Actually Requires
Article 13 of the EU AI Act requires providers of high-risk AI systems to ensure their systems are transparent to deployers. Specifically, it mandates that the system's outputs are interpretable and that deployers receive enough information to understand:
- What the system does and what it doesn't do
- The circumstances under which the system may fail or produce errors
- How to correctly interpret the system's outputs
For a fraud detection model, the key outputs are risk scores, decline decisions, and any explanations or reasoning attached to them.
The article requires that information enabling deployers to understand the system's operations be provided through the Instructions for Use (Article 13(3)(b)) — a document (or section of your technical documentation) that describes, in non-technical terms, what the model does and how to interpret what it returns.
Critically, Article 13 does not require you to fully explain every algorithm in your model. It requires you to provide the information a deployer (your buyer, the payment processor) needs to operate your system responsibly and to communicate appropriately with ultimate users (cardholders, merchants).
What Your Buyer Is Actually Asking
When a payments processor asks about transaction decline explanations, they're typically trying to answer two internal questions:
Operational: "What information will our ops team see when a transaction is declined by your model, and can they act on it?" They need to know if your API response includes a reason code, risk factor list, or confidence score that their team can interpret.
Regulatory: "Can we meet our own obligation to tell a customer why their payment was declined?" Under PSD2 and various national regulations, payment institutions often have obligations to communicate decline reasons to cardholders. They need to know your model gives them enough to do that.
Your answer needs to address both.
How to Answer the Question
Here is a sample response structure that directly addresses what a procurement team needs.
On transparency and explainability:
"When [Product Name] returns a decline signal, the API response includes: (1) a risk score in the range 0-100, (2) the top three contributing feature categories (e.g., velocity pattern, device anomaly, address mismatch), and (3) a human-readable summary of the primary decline reason. This information is returned synchronously and can be surfaced in merchant-facing and cardholder-facing communications.
Our Instructions for Use document (included as Appendix A to this questionnaire) describes how to interpret each field in the API response and which combinations of features typically indicate each risk category. We do not surface individual training data points or model weights."
On deployer obligations:
"We provide deployers with the feature-level reason codes needed to generate a customer-facing explanation that meets the requirements of PSD2 Article 72 and Article 13 of the EU AI Act. Our standard API documentation includes a reason code mapping guide that translates technical outputs into plain-language decline reasons. Deployers remain responsible for drafting their own customer-facing communications using these reason codes."
The Documentation You Should Prepare
To fully satisfy an Article 13 question, you typically need three things.
Instructions for Use. A document that explains, in plain language: what the model's inputs and outputs are, what each output value means (risk score ranges, reason codes), known limitations (e.g., "the model may perform differently on cross-border transactions from high-fraud geographies"), and how to interpret edge cases.
API Documentation with Reason Codes. A reference guide mapping each technical output to a human-readable interpretation. This is what allows a payment processor's operations team to communicate a decline reason to a merchant or cardholder.
Limitations Disclosure. A brief section on known cases where the model may produce uncertain outputs — for example, transactions from new market segments outside the training data distribution.
What Article 13 Does Not Require
Article 13 doesn't require you to:
- Publish model architecture or weights
- Provide individual-level explanations to end users (that's Article 86, which applies to affected persons separately)
- Guarantee 100% accuracy of explanations
- Disclose proprietary feature engineering
Your buyer doesn't expect a PhD dissertation. They expect evidence that you've thought through what their ops team will see and what a cardholder can be told.
Handling the Follow-Up Questions
Procurement teams frequently follow up with:
"Does your explanation capability meet XAI standards? Which framework do you use?"
A good answer: "Our explanation outputs are generated using [SHAP / LIME / feature attribution methods]. We make no claim to use a specific named XAI certification framework, as no standardized framework is mandated by the EU AI Act. Our approach is designed to produce the feature-level attribution data needed to satisfy Article 13(3) of the EU AI Act."
"Can we see an example API response with decline reason codes?"
Include a sanitized example in your documentation appendix. This is often the single most persuasive piece of evidence in a procurement review.
How Complizo Helps
Complizo is a questionnaire answer engine for B2B SaaS companies. When a payment processor sends your team an EU AI Act questionnaire, Complizo reads your existing technical documentation and generates precise, regulation-specific answers — including sample Article 13 responses — in minutes rather than days.
Try Complizo free at complizo.com