A correction visible to a bank employee does not show what a later AI-assisted decision used; the missing link is testable and needs an accountable owner.
Executive takeaways
- A corrected record is not proof of a corrected decision input. Banks need to trace the authoritative change through downstream data transformations to the value actually used at decision time.
- Control design and control operation are different. A documented refresh schedule cannot establish that a correction reached every relevant workflow or that an exception was handled.
- Preserve both the corrected state and the historical evidence. Subsequent decisions must follow the applicable correction and interim-treatment rules; earlier decisions must remain reconstructible within the relevant retention requirements.
The decision a bank must make
A customer disputes an account classification. The bank approves a correction, and the servicing screen displays the new value. Minutes later, an AI-assisted servicing workflow may still read the previous classification from a stored feature that has not refreshed.
The employee sees a corrected record. The model may see an outdated input. Neither observation, by itself, establishes whether the resulting customer outcome was wrong.
That distinction matters to the executive responsible for AI-assisted servicing. A bank cannot establish effective correction handling merely by showing that its source database changed. It must be able to identify which customer data each in-scope decision consumed, when the correction was effective, what happened while downstream data remained unresolved, and which exception controls operated.
The leadership decision is to establish an owned, measurable correction-to-decision control—not assume that the customer-service update completes the process.
The failure sits between systems that may each appear to work
An AI system often uses features: values derived from source data and made available to a model or decision workflow. A feature may be stored separately from the bank’s authoritative customer record and refreshed periodically or when an event arrives.
This creates a plausible mismatch. The authoritative record may contain a correction while a downstream feature store, cache, data pipeline or third-party service still supplies the old value. A delayed update, failed replication, reordered event or replayed older message can complicate the sequence further.
The underlying defect may arise in enterprise data synchronisation, cache management or feature-pipeline operations rather than in the AI model itself. The examination therefore needs to establish which data state the decision consumed, whether the applicable interim rule operated, and whether the original decision can be reconstructed.
Not every delay constitutes a control failure. The bank needs to define when a correction becomes authoritative for each use case, whether a decision can safely continue during a pending update, and what fallback or human review is required. A correction approved at a given minute does not necessarily require an instantaneous refresh across every architecture. But the permitted delay and interim behaviour must be deliberate, documented and testable.
There is also a recordkeeping constraint. Refreshing downstream values must not erase the inputs, model version and other context needed to reconstruct an earlier decision. The institution should distinguish the historical record of what was used from the corrected state that should govern later decisions under its approved rules.
What the RBI material establishes—and does not
In India, the Reserve Bank of India (RBI) published its Committee Report on the Framework for Responsible and Ethical Enablement of Artificial Intelligence (FREE-AI) on 13 August 2025. It contains 26 recommendations organised under six strategic pillars. Four recommendations are particularly relevant to the governance questions in this article: [1, 2]
- Recommendation 15 — Data lifecycle governance: institutional controls for data collection, use, retention and deletion.
- Recommendation 16 — AI system governance: model lifecycle documentation, validation, monitoring and appropriate oversight.
- Recommendation 18 — Consumer protection: transparency, fairness and accessible customer recourse.
- Recommendation 24 — AI audit framework: risk-proportionate examination of data inputs, models and decision outputs, including third-party audits for high-risk or complex uses.
These are committee recommendations, not, by themselves, a binding requirement to perform this specific correction-propagation test or to meet a particular refresh deadline.
The RBI also released draft guidance on model risk management on 24 June 2026 and draft guidance on data governance on 15 July 2026. The respective proposals address model governance and oversight, and data governance topics including architecture, metadata, lineage and quality. Their draft status matters: they should not be presented as operative requirements solely because they are published on the RBI website. [3–5]
Together, these materials supply policy context for a narrower operational question developed by ODA3 Institute: whether the bank can demonstrate that the inputs used in a decision reflect the corrections and interim rules that applied at that time. The proposed test is ODA3 analysis, not an RBI-prescribed method.
The evidence must connect correction, feature and decision
A review should begin with one in-scope customer journey and a specific acceptance criterion. The bank’s data owner supplies the authoritative record, correction approval, effective time and prior value. The technology and AI platform teams supply the lineage through transformations, feature versions and decision-time inputs. Operations and compliance supply the interim-treatment rule, exception handling and customer-review arrangements.
Where a provider operates part of the chain, the bank needs access to sufficient records to examine the provider’s asserted behaviour. A diagram or service-level agreement describes the intended arrangement; neither substitutes for an observed decision record.
| Executive question | Evidence to examine | What a bounded examination can establish | What remains uncertain |
|---|---|---|---|
| When did the correction become authoritative? | Dispute resolution, approval, source-record history, effective-time semantics | The approved value and effective time for the sampled case | Whether the underlying dispute was resolved correctly |
| What value reached the decision? | Transformation lineage, feature snapshot, decision input and identifier, timestamps | The input actually consumed in the sampled journey | Unobserved services, versions or concurrent requests |
| What happened during propagation delay? | Refresh records, queue state, retries, error and exception logs, interim-treatment rule | Whether the defined rule operated during tested delays | Behaviour under other loads and failure conditions |
| Can the earlier decision be reconstructed? | Retained inputs, model/rule version, decision output, provenance and retention records | Whether a sampled earlier decision can be explained or replayed within the stated method | Legal sufficiency and long-term completeness of records |
| What happens when delivery is duplicated or out of order? | Controlled replay tests, event sequence and version checks | Whether tested stale or replayed updates overwrite newer state or trigger an exception | Failure modes outside the test scope |
An independent examiner can assess the stated criterion against source records and repeated tests, recording both successful and unsuccessful cases. The finding must identify the sampled systems, model or workflow versions, observation period, test conditions and missing evidence. It cannot establish bank-wide correctness, customer fairness or regulatory compliance from those samples alone.
Illustrative scenario — synthetic, not based on an examined system
At 10:02, a bank approves a correction to a customer classification and records 10:02 as the effective time. At 10:03, the servicing screen displays the new classification. At 10:05, an AI-assisted workflow uses a feature snapshot containing the previous value because the downstream update has not arrived.
An examiner would first establish the bank’s rule for decisions during that interval. If the approved rule requires the workflow to defer, route for human review or use the corrected value immediately, the 10:05 event can be tested against that requirement. If a controlled delay is permitted, the examiner instead tests whether the decision occurred within the authorised window and whether the interim safeguards operated.
The examiner would then replay the journey with delayed and out-of-order updates, bind each output to the feature snapshot and decision identifier, and check that the earlier decision remains reconstructible after the corrected value is propagated.
Two results must be kept separate: the workflow consumed a superseded value and that input produced a materially incorrect or harmful decision. The first may be established from input records. The second requires examination of the decision logic, the counterfactual outcome and, where relevant, customer impact. Neither result has been established for an actual bank in this article.
Board and executive actions
This is a cross-functional control, not simply a cache-refresh problem. Management owns the policy, data and operational response. Independent reviewers determine what the available evidence supports; they do not take over the bank’s deployment decisions.
| Action | Accountable owner | Decision and condition for reassessment |
|---|---|---|
| Establish a correction-to-decision service target for defined journeys | Head of Servicing, supported by Chief Data Officer | Define effective-time rules and permissible delays; revisit after observing actual latency and exceptions |
| Require decision-level input lineage and reconstruction records | Chief Technology Officer / AI Platform Lead | Demonstrate source-to-feature-to-decision linkage; escalate if a provider cannot supply records |
| Define interim treatment and human escalation for pending corrections | Chief Operating Officer and Compliance | Approve continue/defer/review rules by decision criticality; revise when tested outcomes contradict the policy |
| Commission bounded testing of delayed, duplicated and out-of-order updates | Chief Risk Officer / Independent Assurance Function | Approve scope, criteria and provenance requirements; expand tests if exceptions or missing records emerge |
| Receive reporting on untraceable journeys and unresolved exceptions | Board Risk Committee | Review denominators, observation window, aged exceptions and corrective actions; do not treat missing telemetry as zero failures |
The first management report should distinguish at least three populations: decisions demonstrably using the applicable corrected state; decisions handled under an authorised interim rule; and decisions whose correction-to-input path cannot be established. The third category is unknown, not automatically a failed control or a compliant one.
Notably Absent
This article does not report an examination of a bank, its production decision logs, its customers or its third-party providers. No frequency or severity estimate for this particular failure mode was established from the sources reviewed. No actual customer loss, regulatory breach, legal liability or model fairness finding is asserted.
The cited RBI committee report does not prescribe the correction-to-decision test described here. The two additional RBI materials were issued as drafts; publication of a draft does not establish a final requirement. Absence from the sources reviewed is not proof that such events or practices do not exist.
The operational conclusion
A customer record can be corrected while a later AI-assisted decision still reads an older value. A source-system update therefore cannot stand in for evidence of decision-time data integrity.
Banks should set a scoped correction-to-decision rule, retain the records needed to reconstruct historical decisions, test propagation and exception handling under adverse conditions, and report what remains untraceable. The resulting conclusion must stay within the conditions actually examined.
The Board’s useful question is not whether the customer record was corrected. It is whether management can show what the next decision actually used—and what happened when the correction had not yet arrived.
References
[1] Reserve Bank of India, FREE-AI Committee Report — Framework for Responsible and Ethical Enablement of Artificial Intelligence, 13 August 2025. https://rbi.org.in/scripts/PublicationReportDetails.aspx?ID=1306 (accessed 11 November 2026)
[2] Reserve Bank of India, press release, Report of the Committee to develop a Framework for Responsible and Ethical Enablement of Artificial Intelligence (FREE-AI) in the Financial Sector, 13 August 2025. https://rbi.org.in/Scripts/BS_PressReleaseDisplay.aspx?prid=61018 (accessed 11 November 2026)
[3] Reserve Bank of India, press release, RBI issues draft ‘Guidance on Regulatory Principles for Model Risk Management’, 24 June 2026. https://rbi.org.in/scripts/BS_PressReleaseDisplay.aspx?prid=63006 (accessed 11 November 2026)
[4] Reserve Bank of India, Draft Guidance on Regulatory Principles for Model Risk Management, 2026. https://www.rbi.org.in/scripts/bs_viewcontent.aspx?Id=5089 (accessed 11 November 2026)
[5] Reserve Bank of India, press release, RBI issues draft ‘Guidance on Regulatory Expectations for Data Governance’, 15 July 2026. https://www.rbi.org.in/Scripts/BS_PressReleaseDisplay.aspx?prid=63155 (accessed 11 November 2026)
Methodology note
Source-bounded analysis and synthetic timeline; trace authoritative correction and effective time through feature version and decision input; examine interim-treatment criteria, adverse updates, original decision reconstruction, unknown paths and residual exceptions
Notably Absent
No examined operating bank, customer, decision system or provider; no prevalence estimate; no measured customer harm, regulatory breach, fairness or liability determination; no RBI-prescribed correction propagation test; no insurance conclusion
