Banking data quality challenges

Plain language meaning

Banking data quality challenges explain why missing values, stale records, duplicate customers, inconsistent identifiers, unstructured party information, late events, broken lineage and unreconciled totals can damage every downstream AI decision.

This topic is about data quality in regulated banking AI. It is not about cosmetic cleansing or making dashboards look neat.

In a real bank, this is not a loose technology choice. It affects customer outcomes, operational queues, payment execution, risk decisions, regulatory evidence, audit replay, privacy obligations and production resilience. AI should improve decision support and operating quality, but it must remain inside clear banking ownership and control boundaries.

Where it sits in the banking AI journey

This card belongs to AI Data and Model Operations. The working flow is Source data, Quality checks, Exception triage, Correction and approval, and Trusted AI input.

Read the flow as a bank operating model. Every stage needs a business owner, a source system, a data definition, a timing rule, an exception path, a fallback option, a monitoring requirement and retained evidence. That is the difference between a useful AI pattern and an uncontrolled technology shortcut.

Banking data and evidence

The important data points are customer ID, account ID, party name, address, transaction amount, event timestamp, source total, and quality score. These items matter because they can alter risk scoring, payment treatment, customer communication, operational priority, reconciliation status, compliance review, model monitoring and management reporting.

The evidence pack should include quality dashboard, exception list, correction note, source reconciliation, approval timestamp, data lineage, and defect trend. A strong bank can replay the journey from source data to transformed input, model or rule output, human action, system outcome and monitoring result. A weak bank only knows that a process ran.

Controls that make AI adoption safe

The core controls are completeness rule, validity rule, freshness rule, duplicate check, reconciliation threshold, issue owner, and approval workflow. These controls stop AI from drifting away from banking purpose, approved policy, data governance, model-risk expectations, operational resilience, customer fairness and auditability.

The practical design should define what AI may recommend, what it must never decide alone, which deterministic rule remains authoritative, who owns overrides, how degraded service is handled and what evidence is retained. Without that, the bank may gain speed but lose explainability and control.

Data, architecture and resilience lens

AI in banking depends on the quality of the surrounding architecture. The model can only be as reliable as the data contracts, event meanings, feature definitions, API controls, batch controls, reconciliation rules, monitoring signals and fallback processes that feed and govern it.

A bank-grade design therefore connects channels, source systems, payment hubs, risk systems, data platforms, feature stores, model serving, policy engines, case tools, audit logs and reporting layers. It also defines degraded operation, recovery evidence and post-incident learning before production use.

Regulatory and governance lens

Federal Reserve SR 26-2, dated 17 April 2026, gives revised model-risk guidance for traditional models and non-generative AI models used by banking organisations, including development, validation, monitoring, change control and governance.

NIST AI RMF 1.0 uses Govern, Map, Measure and Manage functions for AI risk management, and NIST AI 600-1 adds generative-AI risk actions for source grounding, content provenance, data protection, security and human oversight.

BCBS 239 remains current for effective risk data aggregation and risk reporting, and the Basel Committee's January 2026 newsletter reiterates the importance of accurate, comprehensive and timely data capabilities in banks.

FFIEC Architecture, Infrastructure and Operations guidance expects financial-institution technology environments to be governed, resilient, secure, monitored, documented and aligned to business risk.

CPMI's February 2026 updated harmonised ISO 20022 data requirements show why consistent structured data matters for interoperable cross-border payment processing and monitoring.

CPMI-IOSCO Principles for Financial Market Infrastructures explain governance, comprehensive risk management, liquidity risk, settlement finality and operational reliability for payment, clearing and settlement systems.

OFAC's Framework for Compliance Commitments describes sanctions compliance programme components including management commitment, risk assessment, internal controls, testing and auditing, and training.

FFIEC BSA/AML examination guidance expects suspicious activity monitoring systems to be risk-based, explainable by management, periodically reviewed and independently validated where appropriate.

Diagram walkthrough

Read the diagram from left to right as Source data, Quality checks, Exception triage, Correction and approval, and Trusted AI input. It is a control map, not decoration. It shows how banking data, AI support, policy control, human accountability and audit evidence should connect.

Use it as a 30-minute study method. For each box, ask which system creates the data, which rule or model acts on it, what can go wrong, who can override it, how the fallback works, what customer or regulatory impact exists and what evidence proves the final state.

Most important mistake to avoid

The common failure is believing AI can compensate for poor data, when poor data usually turns model sophistication into faster and more confident wrong decisions.

The correction is disciplined scope. Keep the topic anchored to banking purpose, prove the data path, make ownership visible, test failure behaviour, record the evidence and make the final outcome explainable without depending on memory or assumptions.

A quality defect with a business consequence

Imagine a lender receives an overnight account file with 100,000 records. Its load job reports success, yet 6,000 balances are null because one source changed a column name. A model may still return scores if it replaces nulls with a training-time default, but the scores are not evidence that the feed is healthy. The bank should reconcile expected versus received accounts, count missing values by source and product, inspect distribution shifts, and decide whether scoring can be published under an approved exception process. A technical green status cannot substitute for business acceptance.

Quality has several dimensions. Completeness asks whether eligible records and required fields arrived. Accuracy asks whether values match authoritative records. Timeliness asks whether they were available for the intended decision. Consistency checks definitions across systems. Uniqueness catches duplicate identities or events. Validity checks type, range and code-set rules. These measures need a denominator, date, owner and action threshold. A 99% populated field can still be unusable if the missing 1% is concentrated in one customer group or a high-risk channel.

A concrete triage separates a source defect from a population change. The owner compares raw files, transformation logs, schema versions and affected decision IDs. If a conversion of minor currency units is wrong, merely retraining a model on the distorted values would institutionalise the mistake. The team may need to stop a feed, replay a dated snapshot, review prior customer decisions, and document a correction. The severity and response depend on the product, legal obligations and customer harm, not only a generic data-quality score.

For acceptance tests, inject a missing file, duplicated account, stale reference table, impossible balance and late correction. Verify that each is detected before a downstream report or decision silently treats it as complete. Record who can waive a rule and for how long, with compensating review. The Basel Committee's BCBS 239 principles concern risk data aggregation and reporting for systemically important banks; their scope should not be generalized to every bank or AI pipeline. They are a useful reference for explaining why accuracy, completeness, timeliness and governance matter when data feeds risk decisions.

Quality is tied to a decision

Banking data quality is not a single score. A payment fraud model needs timely, complete and correctly ordered events before authorization; a monthly credit model needs stable definitions and a reproducible observation window; a compliance assistant needs current, approved documents with effective dates. A value can be accurate in a ledger yet unsuitable for the model's decision time. Quality criteria should start with the business action, the harm from an error and the evidence required to detect it.

Define the unit of analysis first. Is the row a payment instruction, a transaction posting, an authorization attempt, a customer, a facility, an alert or a case? Duplicate technical retries may look like extra payments. A corrected posting may look like a second financial event. An account can have several owners. If teams disagree on the unit, completeness, uniqueness and model labels cannot be measured consistently.

An effective quality contract names the source owner, field meaning, accepted values, timestamp semantics, update cadence, expected population, correction rules and consumer. It identifies critical fields and explicitly states the behavior when they fail. A dashboard reporting 99.9 percent complete records can conceal that the missing 0.1 percent contains all high-value cross-border payments. Report affected decisions and risk segments alongside row counts.

Completeness and population coverage

Completeness asks whether required fields are present and whether the expected records arrived. A non-null amount does not prove that an entire batch was received. Reconcile counts and totals from source partitions to curated tables, feature computations, model requests and final actions. Use sequence numbers, source control totals, watermarks or ledger balances where available. Record exclusions such as canceled instructions and document why totals differ.

Population coverage asks whose data is absent. A mobile channel may be well represented while branch transactions are late. New customers may lack historical features. Small businesses may be mapped into consumer categories. A model can perform well on the visible population and fail where the source process is weakest. Measure missingness by channel, product, geography, account age and other relevant segments, subject to privacy controls. Escalate a concentrated gap even if the global metric stays green.

Missing values have different meanings. No prior transfers is a valid zero count. A source feed not yet processed means unknown. A customer declining optional data collection can mean unavailable by choice. A bureau response failing to match an applicant is a distinct event. Represent these states separately where they change decisions. Filling all missing values with the median can be statistically convenient but may hide a broken feed or create unfair outcomes.

Accuracy and reconciliation

Accuracy can be checked against an authoritative source, a control total or a sampled original document. Payment amounts and currencies should reconcile to the hub or ledger under specified timing rules. Credit balances should be tied to facility and accounting definitions. Case dispositions require a governed status vocabulary. An LLM-extracted value from a document should retain a source span, confidence or review status, and a path for correction. An apparently precise value without provenance can be more dangerous than an explicit missing value.

Two systems can both be correct under different definitions. A ledger balance may reflect posted items while a channel balance includes pending holds. A card authorization and clearing amount may differ because of tips or currency conversion. A fraud feature using authorization data should not be validated by demanding exact equality with later settlement. Define the relationship and expected tolerance rather than labeling every difference an error.

Sampling must target difficult cases: reversals, partial payments, joint accounts, overnight boundaries, long narratives, nonstandard names and migrated products. A random sample dominated by ordinary cases can miss systematic defects. Record the sample method, observed failure modes and affected population estimate. Manual review is most useful when it tests a concrete data definition, not when reviewers merely say a row looks plausible.

Timeliness and the clock

A real-time feature may need an event within seconds, while a regulatory report may tolerate an overnight controlled batch. Define event time, source commit time, ingestion time, transformation time and decision time. The difference between them tells operators whether a value was fresh enough at the moment of use. A timestamp copied from the source without a timezone or business-day convention can shift a feature window around midnight.

Late-arriving events are not necessarily corrupt. Cross-border payment messages, offline card transactions and delayed case updates can arrive after an initial decision. The pipeline should specify a watermark, allowed lateness, backfill behavior and replay policy. Online decisions should not silently change when history is corrected; the bank should preserve the original input and assess whether any affected actions need review.

A stream can be current in aggregate while one source partition is stuck. Monitor maximum and distribution of lag per source and critical segment. If a feature depends on both card and transfer feeds, report freshness of each. A single dashboard showing the newest event can hide an old but essential partition. Tie the freshness gate to model input validity and an approved fallback.

Consistency and semantic drift

Consistency checks whether the same concept has the same meaning across systems and time. A "customer" may refer to a legal person, household, account holder or digital user. A "default" can mean different delinquency thresholds and cure rules. A payment "success" may mean accepted by the hub, settled or merely acknowledged. Models trained on one interpretation should not be served values built from another.

Schemas can remain syntactically unchanged while meaning drifts. A source team may start using an existing code for a new product. A merger may combine branch identifiers. A case workflow may add a new closure reason under a generic status. Monitor category frequencies, unknown codes and distribution changes, but validate suspected drift with business owners. A statistical shift can reflect genuine behavior rather than a defect; a stable distribution can still mask a wrong mapping affecting a small group.

Version definitions and transformations. Keep sample records before and after source migrations and compare model inputs and actions. A contract change should state when the new meaning becomes effective and which historical data requires reprocessing. Test online and offline feature parity on the same decision IDs. A model release is incomplete if its training data uses an old semantic definition while production uses the new one.

Uniqueness, linkage and identity

Uniqueness depends on scope. A transaction ID may be unique only within a source or business date. A payment can have multiple lifecycle events, and a retry should share a business instruction ID while retaining its own attempt ID. Assertions should specify which key and granularity are expected to be unique. Deduplicating on amount and timestamp can merge legitimate similar payments; accepting every retry can inflate fraud velocity.

Entity linkage creates additional quality risk. A false customer merge can attach someone else's transactions to a borrower. A missed match can split an AML network or make a beneficiary appear new. Record match method, confidence where applicable, relationship type, effective interval and correction history. Validate a sample of high-impact links and estimate downstream decisions affected by changes. Identity resolution is an input with measurable error, not an invisible preprocessing step.

An unresolved identifier should not automatically become a new customer. Depending on the use case, the bank may set a missingness flag, refer the case or use a validated limited feature set. A credit decision and a marketing recommendation have different tolerances. Document the action and monitor unresolved rates by source, channel and population.

Labels and outcome quality

Machine-learning labels are often weaker than operational teams assume. A fraud case can be suspected, confirmed, reversed or unresolved. A chargeback is not always fraud. An AML alert closed without escalation is not proof that no illicit activity occurred. Credit default labels require a horizon and treatment of restructures, write-offs and incomplete observation. Define the label source, maturity period, inclusion rules and revision process.

Label leakage occurs when a field created after the decision enters training as a predictive feature. Examples include investigation status, collection treatment, dispute outcome and an updated risk category assigned after a loss. A point-in-time build should enforce feature cutoffs and inspect high-signal fields for suspicious timing. A perfect validation metric can be evidence of leakage. Independently replay sample rows from information available at the original decision.

Selective observation complicates evaluation. Declined transactions do not develop the same outcomes as approved ones, and rejected credit applicants do not produce loan performance for that application. Missing labels cannot all be coded as negative outcomes. Document the observed population and examine how prior policies shaped it. Compare performance across matured cohorts and report uncertainty rather than claiming a universal error rate from an incomplete set.

Documents and generative AI

For retrieval-augmented generation, data quality includes document authority, version, effective date, access scope, extraction fidelity and index coverage. A retrieved paragraph can be textually correct but obsolete. OCR can swap digits in a policy limit. A draft document can be mistaken for an approved procedure. The corpus owner should approve sources and changes; the retrieval system should retain document identifiers and versions for each answer.

Test questions with competing versions, missing answers, lengthy tables and restricted documents. Verify that citations support the exact claim, not merely the topic. Measure whether the assistant abstains when no authoritative source is present. A generic relevance score is not enough when a single wrong effective date changes the banking action. Human review should see source spans and document status.

Prompt and tool inputs may contain sensitive data. A data-quality process should not copy raw customer documents into broad observability logs to make debugging easier. Use controlled samples, masking and authorized drill-down. If a source correction affects an assistant response, retain the earlier draft and investigate whether it was used; updating the index does not erase the earlier impact.

Monitoring design

Put checks at source intake, transformation, feature computation and decision use. Intake detects missing partitions, schema changes and invalid records. Transformation checks joins, cardinality, mapping coverage and reconciliation. Feature checks freshness, null states and distribution. Decision monitoring measures which requests were accepted, rejected, sent to fallback or acted upon. A source alert without downstream impact estimates can be hard to prioritize; a model alert without source diagnosis can lead to unnecessary retraining.

Set thresholds by criticality and expected behavior. A single missing mandatory screening status may require immediate escalation; a small rate of optional narrative fields can be tolerated if the model handles it. Seasonal payment peaks should not trigger false alarms merely because volumes change, but a missing holiday partition should still be detected. Use both absolute counts and rates, and compare to source control totals.

An alert needs an owner, runbook, affected-population query and resolution record. If a pipeline detects a failed check after decisions have already occurred, reverse lineage should identify those decisions and support customer or case remediation. Suppressing a noisy alarm is not equivalent to fixing the underlying definition. Review recurring exceptions and adjust the contract only with evidence.

Incident: duplicated payment events

A streaming connector restarts and replays a partition. The message broker provides at-least-once delivery, and the consumer fails to deduplicate by business instruction and event version. Payment-velocity features double for some customers. The fraud model itself has not changed, but referrals rise for affected accounts. A service-availability dashboard remains green. A quality monitor comparing unique instruction counts and event counts reveals the mismatch.

The incident team freezes or restricts the affected feature path, invokes an approved fallback, identifies the event range and recomputes features. It compares actual model inputs and final actions, not just corrected aggregate features. Some payments may have been held unnecessarily; others may have been released under separate rules. The team documents customer impact, clears duplicate cases and verifies that replayed events do not create new payment actions.

Prevention includes idempotent event handling, source sequence checks, reconciliation and a drill simulating replay. The expected duplicate ratio should be defined for the connector, while a change in distinct business instructions should have its own control. A technical "exactly once" claim should be tested at the business decision boundary.

Incident: stale bureau attributes

A bureau adapter continues returning successful responses while a caching defect serves an old record for a subset of applicants. Completeness and API uptime look healthy. The response metadata indicates an older observation date, and credit-score distributions for the affected channel shift only slightly. A quality gate on record age and match status catches the problem. The bank routes affected applications to an approved review path and preserves the original responses.

The impact analysis links each stale response to feature values, model score, policy rule, underwriter action and final outcome. A recalculated model score alone does not establish that the final decision was wrong; affordability or other controls may have determined it. A correction workflow addresses affected applicants according to the bank's obligations. Monitoring adds age and source-cohort checks, not just an additional global uptime metric.

Incident: obsolete policy corpus

A retrieval index includes a procedure that was superseded last week. The assistant answers a staff question with a persuasive citation to that obsolete text. The data defect is document authority and effective-date handling, even though the text extraction and vector search work as designed. The response trail identifies the index version, retrieved document and reviewers who used the draft. The bank can disable the topic, restore the approved corpus and review any affected communications.

The test suite should include a question whose answer differs between old and current policies, a future-effective version and a topic with no answer. Source owners approve the corpus state. The assistant's response quality is measured against authoritative sources and final use, not merely whether it generated readable prose.

Release acceptance

Before release, select representative decision records and reconstruct their source values, time cutoffs, joins, feature states, model outputs and final actions. Inject a missing partition, duplicate retry, conflicting customer mapping, stale reference, late outcome and invalid document version. Verify detection, approved degraded behavior, affected-decision identification and recovery evidence. Check the quality results by critical segment and expected volume.

Sign-off should name the business decision owner, source owner, data steward, model owner and operations responder. Record open exceptions with scope and expiry. A quality metric has value only when it changes the operating decision or directs a repair. The goal is to know when data is fit for a particular AI use, when it is not, and what the bank did for the customers and cases affected.

Design a quality scorecard

Build a scorecard for a payment fraud feature pipeline with separate rows for event arrival, identity mapping, feature computation and decision use. For event arrival, show expected and received partitions, unique business instructions, duplicate attempts and lag percentiles. For identity mapping, show unresolved payer and payee rates and conflicting active links. For features, show freshness by input source, invalid values, missingness states and differences between online and offline computations. For decisions, show eligible instructions, scored instructions, rule-only fallbacks, manual referrals and terminal statuses. Every row should have a source owner, check frequency, threshold, investigation link and affected-population query.

The scorecard should preserve history of breaches and corrections. A weekly average may hide a 20-minute incident at peak traffic. Use time windows matched to decision latency. A batch credit pipeline can show run completeness and reconciliation before release, plus drift across monthly cohorts. A retrieval corpus can show approved-source coverage, expired-document count, indexing lag and citation verification on sampled answers. Do not collapse these into one composite "data quality score" if the components have different consequences.

Place a stopping rule next to a critical check. If the screening-list feed is unavailable, follow the relevant compliance control. If a fraud feature is stale, switch to the approved policy path for affected transactions. If an optional descriptive field is missing, a validated model may continue with a missingness flag. If a credit label feed is late, block performance reporting or retraining that depends on it while preserving the current decision service if its inputs are sound. This separation prevents a monitoring issue from triggering the wrong operational response.

Quantify impact without overclaiming

When a defect is found, define the exposure window from the last verified good record to the first verified repair. Query decisions that actually consumed the defective field or mapping, not every decision during the window. Record the model version and action for each. Recompute a counterfactual feature where reliable corrected source data exists, then compare scores and policy outcomes. A changed score is a signal for review; it does not by itself prove customer harm. An unchanged score may still conceal a defect in a mandatory rule or a generated explanation.

Estimate uncertainty. If some source records cannot be reconstructed, report the number and characteristics of unresolved cases. If fraud labels are immature, report early indicators and a later review date. If a model output was only advice and a human independently rejected it, distinguish that from a fully automated action. Provide separate counts for exposure, changed features, changed decisions and confirmed customer outcomes.

Prioritize remediation by potential harm, legal obligations and reversibility. A wrongly delayed payment may need prompt communication; an adverse credit decision may need a formal correction process; a flawed management forecast may require a revised report and decision review. The data team can repair the source, but the business owner must handle the actual decision and customer impact. Keep an audit trail of both.

Quality during model development

Exploratory training data often comes from convenience extracts. Before treating results as production evidence, compare extract coverage with the intended live population. Trace each feature to source and computation time. Inspect distributions by period and segment, and test unusual cases. A high-performing candidate model trained on a filtered population may fail when deployed to an unfiltered channel. Document exclusions and whether they are feasible and lawful in production.

Split training and validation by the relevant time and entity boundaries. Randomly splitting rows from the same customer, facility or fraud ring can make leakage easy. Use labels mature enough for the evaluation horizon. Preserve a fixed dataset version and query logic for reproducibility. If an upstream team retrospectively repairs history, record whether the experiment used the original or corrected view; rerun critical evaluations when a material correction changes the candidate population.

Inspect feature importance with timing in mind. A post-decision status that predicts losses exceptionally well should be challenged before being celebrated. An apparently innocuous source code may encode a human investigation outcome. Ask the source owner when the field is populated and whether that time is before the intended decision. A model can exploit a quality defect more efficiently than a manual analyst.

Quality at model serving

Validate inputs at the boundary: types, allowed ranges, category version, feature age, required status and cross-field consistency. A payment amount should be nonnegative under the defined event type; an impossible account age should be rejected or flagged; a model serving an old feature schema should not silently coerce a new value. Preserve reason codes for rejected requests and count them by source. A schema-valid input can still be semantically wrong, so monitor distributions and sample decision traces.

Compare live feature calculations with the training contract. An online velocity counter may reset after deployment, creating low values for every customer. If the model accepts them, success-rate monitoring alone will miss the defect. Use shadow recomputation, independent control totals or sampled offline replay. Establish what deviation triggers investigation and what triggers fallback. Test the system with deliberately stale and malformed inputs before release.

Monitor feedback and corrections after decisions. If case workers repeatedly override scores because a source relationship is wrong, capture the reason and send it to the source owner. Do not automatically retrain on overrides as though they were true labels; overrides can reflect policy, workload or incomplete evidence. Separate quality tickets, model errors and policy disagreements so each receives the appropriate repair.

Ownership and change

Give each critical field an accountable producer and each derived feature an accountable consumer. The producer can certify source meaning and update behavior; the consumer can specify required freshness and decision tolerance. A data steward resolves cross-system definitions. Model validation independently challenges whether quality evidence supports the intended use. Operations owns detection and incident routing. When any link is unnamed, the problem is likely to recur after a team change.

For a planned migration, run both old and new feeds on representative traffic, compare records, features and decisions, and retain a rollback path. Test boundary cases such as timezone changes, historic corrections and duplicate messages. For an emergency correction, record the exact population and whether past decisions need review. Update the contract and the validation evidence, not just the transformation code.

The scorecard, source contract, incident procedure and replay test together establish whether a model's inputs remain trustworthy over time. No single dashboard replaces a clear decision about when to continue, refer, pause or repair an AI-enabled banking process.

Hands-on challenge

Suppose a credit model's approval rate falls after a product migration. The API error rate is unchanged, the overall missing-value rate rises only slightly, and repayment labels are not yet mature. Start by comparing eligible application counts and applicant characteristics before and after the migration. Inspect product-code mappings, bureau match outcomes, income and expense features, and referral reasons by channel and segment. Reconstruct ten applications from each period, including the newly mapped products. Check whether the production feature version matches the validation dataset.

Then separate three possible explanations. A genuine change in applicant mix could shift scores while all source contracts remain sound. A mapping defect could make the new products appear as an unknown category or use the wrong affordability policy. A threshold or policy change could reduce approvals without any model-input issue. Each explanation implies a different owner and remedy. Do not retrain the model merely because a dashboard shows lower approval.

Record the evidence that would falsify each explanation. A hand-checked application with a wrong product mapping supports the data defect. A comparison of scores under old and corrected mappings estimates its decision effect. A policy-version trace can isolate a rule change. Segment-level application counts can reveal a mix shift. If the issue affected adverse decisions, the credit business and compliance teams should govern customer review. This is the practical discipline of data quality: translate a signal into a specific, testable cause and an accountable decision response. Keep the original and corrected application snapshots with controlled access so the remediation can be reviewed later. Repeat the source-to-decision check after the mapping fix reaches production, because a corrected table alone does not prove the live feature path is using it.

Quality gate on a partial channel feed

A fraud feature depends on branch and mobile transfers. The mobile feed is complete, but one branch partition is delayed. A global row count can remain near normal while branch customers receive falsely low velocity values. Monitor expected partitions, source control totals and freshness by channel. The feature response should mark affected requests invalid or stale, and policy should use its approved limited path rather than treating missing activity as a valid zero.

After recovery, backfill repairs current state and an analytical view. The bank preserves scores and actions made during the gap, identifies affected instructions and assesses holds or releases. A report should distinguish exposed decisions from those whose final outcome changed. This is a concrete data-quality test: completeness is defined by the eligible decision population and its clock, not a green job status or an aggregate percentage. Repeat it after a source migration with an unchanged schema but a new status-code meaning. The quality gate should detect semantic drift through known examples and distribution checks. Record the business owner who approves the corrected mapping and the date affected decisions were reviewed.