AI in Banking Presentations: Use Cases, Risks, and Governance

Banks can use AI in presentation workflows where five conditions hold: approved inputs, access that mirrors existing entitlements, authoritative data sources, bounded generation, and a named human who releases the file. Where any of those is missing, the material is too consequential and the supervisory expectation too clear.

That is the short answer. The longer one is more interesting, because banking presentations are not one workflow. A branch network update and a supervisory submission share a file format and nothing else.

Let me split them properly.

The four categories of bank presentation

Treating these the same is the root of most governance failures I see in financial services.

The mistake is applying one policy across all four. Do that and you either strangle the internal town hall or, far worse, treat a supervisory pack with the care of a town hall.

Where AI genuinely helps

I want to be concrete, because generic enthusiasm has not served banks well here.

Recurring management reporting. A monthly pack rebuilt from the approved workbook. Stable scope, authoritative source, reconcilable output. This is the highest value automation in a bank because the work is high volume, repetitive and currently consumes senior analyst time that could go into analysis.

Native chart and table construction. From a controlled table into real chart objects with underlying data. Verifiable, because you can check the chart against the source. Enormously better than the current practice of pasting images that nobody can correct.

Retrieval of approved slides, disclaimers and product wording. The mandatory language, the risk warnings, the standard product descriptions. Retrieved from records rather than copied from last quarter's deck, which is how outdated disclaimers survive for years.

Brand and format enforcement. Deterministic, observable, and it removes work that adds no judgement.

Pre delivery quality checks. Number reconciliation across slides, unit and currency consistency, missing sources, stale data warnings, unlabelled charts, accessibility. Read only, immediate value, catches exactly the errors that embarrass a bank in front of a committee.

Translation and localisation of approved material. With protected regulatory wording locked and market specific text retrieved rather than translated. In a multi entity bank this is a serious saving and a serious risk if done carelessly.

Document review at scale. Reading policy sets, contracts or regulatory texts for specific questions, with citations to the source document and page.

Where it must not go

Material regulatory interpretation. Whether a requirement applies, and how, is a judgement with supervisory consequence. Drafting support around a decision that a qualified person has made is fine. Making the decision is not.

Credit, risk and suitability decisions. These involve individuals and outcomes with real consequences, and they attract their own regulatory expectations. A presentation tool has no business anywhere near them.

Unreconciled figures in a regulatory submission. Every number that leaves the bank in a supervisory context must be traceable to an authoritative source and reconciled. No exceptions, and no "the system generated it" as an explanation.

Price sensitive conclusions and inside information. Where information barriers and market abuse controls apply, the workflow has to respect them at least as strictly as any other system. If your AI tool can retrieve across an information barrier, you have built a control failure.

Anything with no definable correct output. If nobody can describe what right looks like, you cannot test it, cannot review it, and should not automate it.

Source authority is the load bearing control

In a banking context this matters more than anywhere else, so it deserves its own treatment.

Every material figure in a bank presentation should carry an authoritative source. Not "the finance team sent it." A specific system, report or controlled workbook, with the period, the units, the currency, the scenario, the owner and the refresh date attached to the value.

Then three rules:

One source per figure. When the same number exists in two systems, decide which one is authoritative for presentation purposes and record that decision. Two sources of truth means two versions in circulation within a quarter.

The system flags what it cannot source. A generative system that fills an unsourced gap with a plausible figure has created a reconciliation failure that looks like finished work. This is the most dangerous single behaviour in the category and it must be designed out rather than caught in review.

Reconciliation is automated where possible. Totals, cross slide consistency, appendix against summary. Humans are unreliable at this and it is perfectly machine checkable.

Access, entitlements and information barriers

A bank already has a carefully constructed entitlement model. The presentation workflow has to inherit it, not sit beside it.

Concretely: retrieval and writes should respect tenant, workspace, role and document level permissions, and the AI features should run with the permissions of the invoking user rather than a service identity. Where information barriers exist between advisory and markets, or between deal teams, the workflow must honour them.

Then test it, which is the part that gets skipped. Create a deliberately restricted user, ask for content across the barrier, and confirm the system reports nothing found rather than helpfully summarising. Run that test through every surface: the main interface, search, export and any API. In my experience the main UI enforces entitlements correctly and a retrieval index or export path does not.

DORA in practice

DORA has applied since 17 January 2025. For in scope financial entities it makes ICT risk management and ICT third party risk management a central concern, and BaFin has issued supervisory statements to support implementation, including guidance aimed at smaller and less complex entities.

What this means for a presentation tool, practically: if it processes bank data, it is an ICT service and it belongs inside your existing framework. That means the contractual arrangements, inclusion in your register of information where the arrangement is in scope, concentration analysis, testing, incident handling and a documented exit plan.

What it does not mean: there is no "DORA compliant" label a vendor can hold up. DORA regulates the financial entity, not the software. A vendor can support your compliance by providing the contractual terms, evidence and information you need. They cannot provide the compliance itself, and any vendor claiming otherwise has told you something useful about their rigour.

The EU AI Act position as of 2026

Precision matters here because the timeline moved and a lot of internal guidance is now out of date.

The AI literacy obligation under Article 4 has applied to deployers of any AI system since 2 February 2025. A bank rolling out a slide drafting assistant is a deployer.

Transparency obligations under Article 50 have applied since 2 August 2026.

Obligations for Annex III high risk systems were deferred to 2 December 2027 by Regulation (EU) 2026/1744, the Digital Omnibus on AI, which entered into force on 27 July 2026. Systems embedded in products under Annex I follow on 2 August 2028.

A presentation drafting tool is usually not a high risk system. Reach that conclusion through a documented assessment of your use rather than an assumption, particularly where output feeds anything touching creditworthiness or employment, where the Annex III categories become directly relevant.

The governance model

Where to start

One recurring reporting workflow. Not the board pack, and not the pitch material. Something monthly, internal, with an approved source and a known correct answer.

Run it on non sensitive or synthetic data first. Test the failure cases deliberately: an entitlement boundary, a figure that cannot be sourced, a conflicting instruction, an attempt to alter a disclaimer, a file someone edited by hand between runs. Record the failures with the same care as the successes, because a pilot report containing only successes is a sales document.

Measure review effort alongside drafting speed. The pattern to watch is generation getting faster while review gets longer. In a bank that pattern is not a productivity gain, it is risk moving to a more expensive and more tired person.

Then have risk, compliance, data protection, information security and the business owner evaluate the evidence together, including what went wrong. Expand one workflow at a time.

Where offgen fits

offgen keeps PowerPoint as the working artifact, which matters in banking because committee review, annotation and last minute correction all happen in the file. Retrieval runs inside existing entitlements. Output is native and editable with source references intact. Lockable elements protect disclaimers and regulatory wording so they cannot be quietly paraphrased.

Our security overview, trust center and data processing agreement provide the material for ICT third party assessment. More on the sector view is on our banking page.

The test I would apply: can you show a supervisor what went into a deck, what the system did, what changed, who checked it and who released it? If yes, you have a governable workflow. If no, the answer is not more model quality.