AI Decision Engine in Banking: Five Building Blocks, One Audit Trail and the Real-Time-or-Batch Question

Tuesday morning, a branch in Berlin-Charlottenburg. Thomas Brandt, 46, a self-employed architect, calls because his card was declined in a Milan restaurant the night before; the fraud system had blocked the payment. At the same moment, the bank's systems hold two further facts about him: the fixed-rate period on his mortgage ends in nine months, and an investment campaign has flagged him as a promising candidate. Three possible actions, one customer, one morning. Which of them the bank carries out, in what order and with what justification, is no longer decided by a campaign list but by a decision engine. The scene is constructed; the question behind it is real for every bank: how must that engine be built so that it makes good decisions and can explain every one of them?

What an AI decision engine in banking actually does

An AI decision engine is the layer between a bank's data and its channels. For every customer and every moment it answers a single question: what is the best action right now, and is it permitted? That distinguishes it from a model that only outputs a probability, and from a campaign tool that only works through a list. We described how predictions belong in the middle of the customer loop rather than at its end in part three of the AEP series, and the path from the propensity list to a checked decision in our article on next best action. This article is about the architecture itself.

The need is well documented. In a poll of attendees at FICO World 2026, 43 percent rated their organisation's ability to personalise as "only basic", 74 percent named data silos and 68 percent legacy systems as the biggest barriers, and most customer profiles were described as static snapshots from the overnight batch (FICO). Gartner published its first Magic Quadrant for decision intelligence platforms in 2026 and expects that by 2027 half of all business decisions will be augmented or automated by AI agents, while warning that by the same year 25 percent of ungoverned decisions made with large language models will cause financial or reputational loss (SD Times). Taken together, that is the brief: automate more decisions, and keep every one of them under control.

Five building blocks, one sequence

A decision engine that can do both consists of five building blocks. The sequence is not arbitrary, because each block constrains the next.

1. Customer state. The starting point is not a segment but the current state of one person: products, limits, consents, open cases, the latest events from app, transactions and service. For Thomas Brandt that includes this morning's call, not tomorrow morning's data extract. The state is the foundation for everything else; if it is stale, the best models are reasoning about the wrong person.

2. Eligibility rules. Before any model runs, deterministic rules filter what is even in scope: product prerequisites, consents, cooling-off periods, age limits, regulatory requirements, internal policies. Eligibility is binary and must stay that way. A 90 percent probability does not replace a missing marketing consent.

3. Models. Only now do the statistical estimates come in: propensity to buy, churn risk, channel preference, payment stress, expected service demand. Models say what is likely. They do not say what is right.

4. Value estimation. Every permitted action receives an expected value, and it is calculated for both sides: contribution margin over the lifetime, avoided cost, risk, and explicitly the cost of lost trust if the action arrives at the wrong moment. Without this block, the engine optimises for clicks.

5. Arbitration and suppression. Finally the scored candidates compete for a slot. Contact budget, priority rules, channel capacity and suppression rules decide which action is executed, which waits and which is discarded. Suppression is not a by-product but a rule set of its own: open complaint, active fraud case, bereavement, dunning stage.

In the Brandt case this means: the customer state has contained an open complaint since 9:14. The eligibility rules admit both the refinancing and the investment account. The models see a high propensity for the refinancing and a medium one for the investment account. Value estimation puts the refinancing far ahead. Arbitration, however, holds both back, because one rule says: no sales contact within five days of an open complaint. The action that wins is a service task for his advisor Nadia Sauer: clarify the card block, call back today. That is the decision, not the offer.

Explainability and audit trail under MaRisk and the AI Act

The example shows why explainability cannot be a property of the model alone. What has to be explained is the decision, and the decision emerges from all five blocks. That is now exactly what supervisors expect.

Since the 2024 revision, Germany's MaRisk contain a dedicated module on the use of models, AT 4.3.5. It applies explicitly to artificial intelligence methods and requires that a model's assumptions are justified and documented, that data quality is assured, that there are rules governing the use of its results and that models are validated regularly; results must be "sufficiently explainable", meaning the relationships between inputs and outputs can be traced (BaFin, Circular 06/2024). In PwC's reading, the module also covers models for technology-supported decision-making that previously sat outside the classic risk-model framework (PwC). A decision engine that steers customer contacts is such a model.

Then there is the AI Act. Since 29 July 2026, BaFin has been the market surveillance authority for AI systems directly connected to a regulated financial activity; it supervises transparency obligations for systems that interact with customers, the ban on certain practices and the requirements for high-risk systems such as creditworthiness assessment, and it makes clear that decisions must remain correctable and reversible by humans (BaFin). Through the omnibus Regulation (EU) 2026/1744, the high-risk obligations under Annex III apply not from August 2026 as originally planned but from 2 December 2027 (European Commission). For deployers that will mean, among other things, human oversight by qualified staff and retention of automatically generated logs for at least six months (Art. 26 AI Act). Most decisions an engine makes in marketing and service are not high-risk; but as soon as the same engine scores limit adjustments or financing offers, it moves towards the boundary. Anyone building the architecture now should build it so that this transition does not require a second architecture. In its Risks in Focus 2026, BaFin states the expectation regardless of risk class: AI outputs must be explainable and verifiable and must not contain bias (BaFin).

Technically, this means the audit trail is not a log of the model but a record of the decision. For every run it captures which customer state applied, which eligibility rules fired, which model version delivered which values, how the value was estimated, which candidates lost in arbitration and which suppression rule applied. Only this record answers the question an auditor or a customer will ask: why did I get this offer, and why not the other one?

Real time or batch: a question per building block

The second architectural question is how fast the engine has to be. The answer differs per building block, and this is where many projects invest either too much or too little.

The customer state must be updated in real time, at least for the events that flip decisions: complaint, suspected fraud, card block, large transaction, intention to leave. An engine that at 9:30 does not yet know the customer called at 9:14 makes the wrong decision, however good its models are. Eligibility rules are evaluated at the moment a decision is due; they are cheap and fast. Models can mostly be computed in batch: propensity and churn risk do not change by the minute, and overnight scores are good enough for most use cases. Event-driven models such as fraud or payment stress are the exception. Value estimation follows the models and rarely needs real time. Arbitration, by contrast, has to run at the moment a channel asks, because only then is it known which channel is asking, how much contact budget has been used and whether a suppression applies.

So the pattern is not "everything in real time" but: state and arbitration in real time, models and value estimation in batch, eligibility on demand. That keeps the engine affordable and still current. How agile rule sets can become is illustrated by a vendor-published example: Banco Santa Cruz in the Dominican Republic reports that, after replacing its legacy system, change cycles for credit policies fell from 90 days to two, with consistent decision logic across mobile, branch and online (FICO Investor Relations). Such figures are vendor claims rather than an industry average; the direction, that rules must be changeable without a release cycle, applies to every engine.

How the decision reaches the advisor

Back to Charlottenburg. That morning Nadia Sauer does not see three campaigns but one task with a reason: card blocked in Milan, customer has called, please call back today; sales topics deferred until resolved. She calls, lifts the block, explains the trigger, the customer is satisfied. When the complaint is closed the customer state changes, the suppression expires, and twelve days later a second suggestion appears on her screen: refinancing, fixed-rate period ends in eight months, high propensity, high value, investment account secondary. With it, three sentences on why now, why this product, and which rule held it back two weeks ago. She books an appointment. The investment account may come later, or never; the engine did not delete it, it ranked it correctly.

What the advisor sees is the surface of the audit trail. What the auditor sees is the same record in full depth. What the customer experiences is a bank that solves his problem first and talks about his financing second. That all three are looking at the same decision is the real purpose of the architecture.

Five takeaways

1. An AI decision engine answers one question for every customer and moment: what is the best action, and is it permitted? That is more than a model and more than a campaign list.

2. The five building blocks of customer state, eligibility rules, models, value estimation and arbitration follow a fixed sequence; each constrains the next, and suppression is a rule set of its own.

3. MaRisk AT 4.3.5 also applies to AI-supported decision models; BaFin has been the market surveillance authority for AI in the financial sector since July 2026, and the AI Act's high-risk obligations apply from 2 December 2027.

4. It is the decision that must be explainable, not just the model; the audit trail therefore records all five blocks, including the candidates that lost.

5. Real time is not a property of the whole engine: state and arbitration in real time, models and value estimation in batch, eligibility on demand.

Illustration: AI-generated. AI-assisted content: We use AI technologies and automated agents in the creation of our articles, including from Microsoft, Google, OpenAI, Anthropic and other providers. Topics, editorial direction and final approval remain with our team.