A contextual bandit is not an optimisation trick you ship and forget. In a regulated banking workflow it is an automated decision system that rewrites its own behaviour every time it acts — and every action is a governed step an examiner can ask about. That single reframing decides whether your first examination goes smoothly or turns into an evidence-reconstruction scramble. The naive view is seductive because it is technically correct in isolation. Pick the action with the best predicted reward. Ship it. Let it learn online from the feedback. Frameworks like Vowpal Wabbit and the contextual-bandit modules in libraries such as contextualbandits make this a few lines of code, and the offline metric — cumulative reward, regret against an oracle — looks great. The problem is not the algorithm. The problem is that the same adaptivity that produces the lift is what makes the model harder to govern, not easier. Why the adaptive part is the compliance-hard part Consider what happens between two examinations. A static scoring model behaves identically on day 1 and day 200 unless someone retrains and redeploys it — a discrete, documented event. A contextual bandit does not work that way. It updates its policy from live feedback, so the mapping from customer context to chosen action drifts continuously. The offer a customer received on a Tuesday was produced by a policy state that no longer exists by Friday. When an examiner asks why did this specific customer receive this specific offer or risk treatment on this specific date, aggregate reward tells you nothing. You cannot re-derive the decision from a throughput chart. A team that logged only the reward curve has optimised a number it can defend statistically and cannot defend individually — and in a banking workflow, the individual decision is the unit of regulatory interest. This is the divergence point named in every model-risk conversation we have with banks piloting online-learning systems. Two teams ship the same bandit. One logs the context vector, the policy version that acted, whether the action came from exploitation or an exploration branch, and how the reward was attributed back. The other logs aggregate metrics. Both pass their offline evaluation. Only one can hand over a decision-level trail. The measurable outcome of getting this right is decision-level auditability with no gap between the optimisation lift you claim and the evidence you can produce to defend it — which is what cuts evidence-gap findings tied to adaptive models per examination (observed across TechnoLynx governance engagements; not a published benchmark). What SR 11-7, fair lending, and adverse action each demand Three distinct regulatory lenses fall on a bandit in a US banking context, and they ask different questions of the same log. SR 11-7 model-risk management treats the bandit as a model that must be documented, validated, and monitored. But a bandit is a model whose parameters change without a release. The documentation has to describe not just the current policy but the process by which the policy evolves — the update rule, the exploration schedule, the guardrails on how far a single update can move behaviour. The exploration policy is itself a governed artefact, and it needs a version like any other model component. Fair-lending scrutiny asks whether the adaptive behaviour introduced disparate impact that was not present at launch. A bandit can learn a proxy for a protected characteristic purely from reward signal, drifting into discriminatory behaviour that no one designed and no static fairness test at deployment would have caught. Reconstructing whether that happened requires the context and action at each decision, indexed by time, so you can slice by cohort after the fact. Adverse-action explainability — the requirement to tell a declined customer why — is the sharpest one. If the bandit chose to explore, the honest answer is that the action was partly a deliberate information-gathering step, not purely a reward-maximising judgement about that customer. You cannot explain that to a customer or an examiner unless you logged the exploration decision as such. This is where our work on what auditors and model-risk reviewers actually need from machine learning explainability meets the specific mechanics of online learning: explainability for an adaptive system is a logging problem before it is a modelling problem. What does the model-risk committee actually need, versus the bandit’s technical metrics? This is the question that separates a clean examination from a painful one, so it is worth answering directly. The bandit’s technical performance metrics and the compliance evidence a model-risk committee needs are two different artefacts that happen to share a data source. Conflating them is the most common failure we see. Concern Technical performance view Compliance evidence view Primary unit Aggregate reward / regret over the population The individual governed decision Question answered Is the policy better than the baseline? Why did this customer get this treatment on this date? Exploration A tunable parameter that trades regret for learning A versioned, governed artefact; a logged branch on each decision Time Convergence curve, roughly monotone An immutable per-decision timeline you can replay Fairness Optional offline check at deployment Continuous, reconstructable per-cohort slicing after the fact What “good” looks like Low regret vs oracle (benchmark-class, offline) Zero gap between claimed lift and defensible per-decision trail (observed-pattern) The right-hand column is the evidence pack. It is not derived from the left-hand column — you cannot reverse-engineer per-decision explainability out of a regret plot. It has to be captured at the moment the bandit acts, or it is gone. The per-decision record: a diagnostic checklist If your bandit logs the following for every action, you can reconstruct any decision against the questions above. If it logs less, you have a gap you will discover at the worst possible time. Use this as a design rubric before the system goes live, not an audit finding after. Decision ID and timestamp — immutable, unique, ordered. This is the primary key an examiner’s question resolves to. Full context vector — the exact features the policy saw, not a reconstruction from upstream tables that may have since changed. Policy version — the identifier of the policy state that acted, resolvable to the update rule and hyperparameters in force at that instant. Exploration flag — whether the chosen action was exploitation or exploration, and which exploration mechanism (epsilon-greedy, Thompson sampling, UCB) fired. Action taken and the alternatives considered — with the predicted reward for each, so you can show the counterfactual. Reward attribution — what feedback was received, when, and how it was joined back to this decision (delayed rewards make this non-trivial). Guardrail state — any fairness or business-rule constraint that was active and whether it clipped the action. The write pattern here is append-only, high-volume, and query-by-key — which is why teams building these trails often reach for a store tuned for exactly that shape. Our note on Cassandra performance under an audit-trail write load covers the tuning that keeps per-decision logging from becoming the bottleneck that tempts a team to log less. Where uncertainty quantification fits Bandits and Bayesian methods overlap — Thompson sampling is a Bayesian exploration strategy — and that overlap is useful for governance, not just for regret. If your policy maintains a posterior over action rewards, you can log the uncertainty that drove an exploration decision, which turns “the model explored here” into “the model explored here because its confidence in the alternatives was below threshold X.” That is a materially stronger adverse-action explanation. The mechanics of treating that posterior as audit evidence are the subject of our piece on Bayesian inference in Python for regulated AI workflows, and the same discipline applies whether the uncertainty is feeding an exploration decision or a risk score. None of this is a reason to avoid contextual bandits. The lift is real, and for high-volume decisioning — offer selection, risk-treatment routing, next-best-action — the adaptive approach genuinely outperforms static models in the settings we have seen (observed-pattern; not a benchmarked rate across all workflows). The point is narrower: the governance cost of an adaptive model is front-loaded into the logging design, and a team that treats logging as an afterthought pays it back with interest at examination. For banks framing this as part of a broader governance posture, the AI governance and trust practice is where these per-decision trails become an evidence pack that maps controls to the exact questions an examiner asks. The bandit-specific addition is one row: the exploration policy and the per-decision log are the versioned artefacts behind the “automated decision” and “model approval” questions. FAQ What is the boundary between the bandit’s technical performance metrics and the compliance evidence a model-risk committee actually needs? They share a data source but answer different questions. Technical metrics — cumulative reward, regret against an oracle — describe the policy’s behaviour over the whole population and tell you whether it beats the baseline. Compliance evidence describes individual governed decisions and answers why a specific customer received a specific treatment on a specific date. You cannot reverse-engineer the second from the first; per-decision context, policy version, exploration branch, and reward attribution must be captured at the moment the bandit acts or they are lost. Contextual bandits earn their measurable lift precisely because they adapt — but that adaptivity is what makes SR 11-7 documentation, fair-lending scrutiny, and adverse-action explainability harder, not easier. The question worth carrying into your next design review is not whether your bandit converges, but whether it logs enough that you could replay any single decision it has ever made — because that is the version of the question an examiner will eventually ask.
