What Happens When You Let AI Explain a Validation Failure Instead of Just Flagging It
Learn how to use AI to speed up the process of reviewing validation errors.
- By Arun Mishra
- August 19, 2026
Typically, what most validation pipelines do when there’s a failure is report some kind of error code or even a line number and leave a human to make sense of what happened. While building a safety gate for ISO 20022 payment files for the upcoming 2026 migration to Fedwire/CHIPS/SWIFT CBPR+, we discovered that the limitations of this approach become quite evident in situations when the people reviewing flagged files aren’t always familiar enough with the schema to interpret a raw validation error. The fix was not to craft a better error message; it was to decouple the validation logic from its presentation.
Where the Standard Approach Breaks Down
Deterministic validators excel at one particular thing: checking whether something conforms to a defined set of rules and reporting the result reliably and reproducibly. What they fail to do is provide context to a human reviewer about why adherence to a rule actually matters. “Field 70 fails constraint X” is accurate and useless in the hands of a reviewer trying to assess whether a payment file has a real problem worth escalating or just a formatting quirk that’s safe to override.
The temptation to fix that with a better error message only goes so far—either you find yourself wasting engineering effort designing a message catalog that is always one edge case behind reality, or you accept that reviewers will keep escalating validation issues to technical staff just to understand what’s going on. Neither is a good outcome.
The former consumes engineering resources that could be spent elsewhere while the latter creates a bottleneck that grows proportionally to your validation volume—the more payment files you validate, the more escalations accumulate, and the people with deep schema knowledge end up interpreting error codes rather than doing actual work.
That’s exactly the kind of problem an explanation layer fixes, and it’s important to clearly recognize what the problem actually is before talking about the solution: it’s not the validation logic. It’s the output of correctly working validation logic being consumed by someone missing the context needed to act on it efficiently.
The Pattern: Deterministic Check, Separate Explanation Layer
The process we ended up with was that the validation logic remains deterministic at all times—schema validation, business rule checks, everything reproducible, consistent, and auditable, with no AI involved in the actual pass/fail decision. On top of this sits another layer that receives the structured result of a failed check and generates a plain-language explanation of what was checked, what was found, and why it matters in this specific context. The AI doesn’t get to participate in the pass/fail decision in any way; it can only explain a decision that has already been made deterministically.
That distinction is crucial for a reason beyond convenience. If you involve a language model in the actual pass/fail decision, you lose the reproducibility of the validation process—when you run the same file twice, you want the same result each time, and a language model cannot provide that guarantee the way a deterministic rule engine can. In a regulated payments environment, that reproducibility isn’t just a nice property to have; it’s what makes the validation auditable, and it’s what an examiner will ask about when they want to understand your control process.
Another benefit of maintaining that strict boundary is that the system becomes far more maintainable. When validation rules need to change—and in a migration period they will—you change them in the deterministic layer, and the explanation layer adapts to the updated output structure. You don’t have to keep two things in sync: a message catalog and a rule engine.
What This Actually Changed for Reviewers
In practice, reviewers spent less time escalating ambiguous validation flags to someone who understood the schema because the explanation layer gave them enough context to make a first-pass judgment themselves. This doesn’t mean escalations are gone—some validation flags still require expert judgment—but the lower volume of “what does this even mean?” questions meaningfully reduced the bottleneck in the review process.
The quality of the remaining escalations also improved. The conversation shifted from “the validator reported error code X, and I don’t know what it means” to “the validator flagged this and here is the plain-language explanation—I’m not sure if this needs expert review.” The explanation layer didn’t remove the need for expert judgment. It made the cases that required that judgment faster to identify and easier to hand off.
Where This Generalizes Beyond Payments
This pattern isn’t specific to ISO 20022 or financial messaging. Any system where a deterministic check produces a technically accurate but unhelpful failure signal can benefit from the same separation. Data quality gates where the people reviewing flagged records are business analysts rather than data engineers. Configuration linting pipelines where the operators remediating failures aren’t the same people who wrote the linting rules. ETL validation layers where a failed constraint needs to be understood by someone in a business function before a decision gets made about whether to proceed.
In all these cases the core issue is the same: the validation is correct, the output is machine-readable, and the person who has to act on it is not a machine. An explanation layer that translates the machine-readable output into something a non-expert can reason about solves that problem without touching the validation logic at all.
The Mistake to Avoid
The pitfall to watch out for is that blurry boundary between the deterministic validation logic and the explanation layer. The moment you blur it—even by mildly softening the language around a finding in a way that influences whether a reviewer escalates it—you’ve traded a reliable, auditable gate for a faster one that’s no longer fully auditable. The explanation layer is supposed to describe the findings of the deterministic layer; it is not supposed to editorialize them. The judgment of whether a finding matters stays with the human reviewer, informed by the explanation, but not replaced by it.
When building something like this, instrument that boundary explicitly: log what the deterministic layer returned and what the explanation layer generated separately, so you can verify over time whether the explanation accurately reflects the finding and hasn’t drifted from it.
About the Author
Arun Mishra is an enterprise architect and senior manager with 16 years of experience in financial services and healthcare technology. In his career, Mishra has rebuilt broken event-streaming pipelines, led cloud migrations moving 820M+ records, recovered stalled post-merger data migrations, designed real-time payments architecture across ACH, RTP, and wire, built ML fraud detection platforms from model training through production, modernized legacy systems nobody wanted to touch, and developed open-source tooling for data migration drift analysis and payment file safety gates. You can reach the author at [email protected] or arunkmishra.com.