ATM-Bargeldbedarfsprognose auf Standortebene

Das echte Ausmaß des Problems

Deutschland hat laut Bundesbank-Zahlungsverkehrsstatistik (Stand 2024) noch rund 51.000 Geldautomaten — trotz eines deutlichen Rückgangs von knapp 59.000 im Jahr 2018. Deutsche Privathaushalte heben dabei im Schnitt 27 Mal pro Jahr Bargeld ab, mit durchschnittlich 253 Euro je Abhebung. Bargeld ist nach wie vor das meistgenutzte Zahlungsmittel an der Ladenkasse.

Für Banken und Sparkassen bedeutet das: Ein Netz aus 100 Automaten ist kein passiver Kanal, sondern ein aktives Logistikproblem. Und es ist ein teures. Laut Diebold Nixdorf macht das Cash Management — die Bargeldlogistik — bis zu 50 Prozent der gesamten Betriebskosten (TCO) eines ATM-Netzwerks aus. Das umfasst:

• CIT-Kosten (Cash-in-Transit): Panzerfahrten sind teuer. Eine standardmäßige Befüllungsfahrt kostet je nach Anbieter, Region und Vertrag zwischen 80 und 250 EUR pro Automat und Besuch.
• Opportunitätskosten des gebundenen Kapitals: Bargeld in einem ATM-Kassetten ist totes Kapital. Bei einem typischen Befüllvolumen von 20.000–60.000 EUR je Automat und einem Zinssatz von 4–5 Prozent p.a. entstehen pro Automat jährlich 800–3.000 EUR Kapitalkosten — nur für das Bargeld, das dort liegt und wartet.
• Leerstands-Schäden: Ein ATM, der leer ist, wenn Kunden Bargeld brauchen, erzeugt Beschwerden, Abwanderung und Reputationsverlust — besonders wenn es ein Freitagabend ist und der nächste Wettbewerbsautomat 100 Meter weiter funktioniert.

Fallahtafti et al. (2022) in SN Computer Science fanden in ihrer Analyse von ATM-Transaktionsdaten, dass Banken im Schnitt 40 Prozent Überschusskapital in Geldautomaten halten — als Puffer gegen Leerstände. Diese Übervorsicht ist verständlich, aber teuer: Bei einem 300-ATM-Netz mit durchschnittlich 40.000 EUR Befüllvolumen und 20 Prozent Überschuss sind das 2,4 Millionen Euro totes Working Capital, das jährlich rund 100.000–120.000 Euro an Zinskosten erzeugt.

Das Kernproblem: Die meisten Netzwerke werden nach festen Intervallen befüllt — unabhängig davon, ob der Automat tatsächlich Bargeld braucht. Das passt zum Dienstleistungsmodell der CIT-Anbieter (feste Routen, planbare Einsätze), aber nicht zur Nachfrage der Kunden, die von Wochentag, Wetter, Veranstaltungen und Monatszyklus abhängt.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Unter stabilen Marktbedingungen; bei starken externen Schocks (z.B. Pandemie-Beginn) können Genauigkeiten initial stark sinken — Modell-Retraining erforderlich.

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5)
Die wöchentliche Kassenplanung für ein ATM-Netz ist ein erheblicher manueller Aufwand: Transaktionsberichte prüfen, Befüllpläne justieren, Sonderereignisse einpflegen. Ein Machine Learning-System übernimmt das automatisch und gibt dem Treasury-Team eine priorisierte Befüllliste statt ein Daten-Konvolut. In der Praxis berichtet das Treasury nach Einführung von einer Reduktion des Planungsaufwands von 4–8 auf unter 1 Stunde pro Woche — bei gleichzeitig besserer Prognosegüte.

Kosteneinsparung — hoch (4/5)
Zwei Hebel greifen gleichzeitig: Weniger CIT-Fahrten (direkter Kostenblock) und reduziertes Working-Capital-Binding (indirekter, aber gut messbarer Effekt). In der finanzen-Branche gehören direkt messbare Logistikkosten zu den stärksten Einsparungspotenzialen — dieser Anwendungsfall ist hier klar überdurchschnittlich, weil beide Hebel nachvollziehbar auf Cent genau abgerechnet werden können.

Schnelle Umsetzung — mittel (3/5)
Transaktionsdaten sind fast immer vorhanden — aber selten in der richtigen Granularität (Stundenbasis pro ATM) sofort verfügbar. Datenextraktion, Bereinigung, Feature Engineering für Saisonalität und Ereigniskalender dauern. Realistisch sind 8–14 Wochen bis zum ersten Piloten mit 10–20 ATMs. Das ist handhabbar, aber nicht trivial — vergleichbar mit der KI-gestützten Liquiditätsplanung in diesem Bereich.

ROI-Sicherheit — sehr hoch (5/5)
Das ist der stärkste Wert in dieser Kategorie: Beide Nutzenkomponenten — CIT-Kosten und Working Capital — sind exakt messbar. Du weißt vorher, was eine Befüllungsfahrt kostet. Du weißt vorher, wie viel Kapital in deinen Automaten steckt. Du kannst den Leerstand-Event im Log nachweisen und seinen Reputationsschaden schätzen. Der ROI-Nachweis ist hier ungewöhnlich direkt — was in der Branche selten ist. Kaum ein anderer Anwendungsfall in diesem Bereich hat so wenig “weiches” Potenzial und so viel Messbares.

Skalierbarkeit — hoch (4/5)
Das Modell skaliert gut: Jeder neue Automat im Netz bekommt sein eigenes Modell auf Basis seiner eigenen Transaktionshistorie. Mehraufwand entsteht nur durch Rechenzeit, nicht durch manuelle Arbeit. Nicht ganz maximal bewertet, weil das Modell-Monitoring mit wachsendem Netz aufwendiger wird — 300 individuelle Standortmodelle zu überwachen ist eine andere Aufgabe als drei.

Richtwerte — stark abhängig von Netzgröße, CIT-Vertragsstruktur und vorhandener Dateninfrastruktur.

Was das Prognosemodell konkret macht

Das Grundprinzip: Statt fester Befüllintervalle berechnet das System täglich für jeden Automaten, wie viel Bargeld er in den nächsten 48–72 Stunden verbrauchen wird — und ob eine Befüllung nötig ist, bevor er leerläuft.

Das Modell lernt aus historischen Transaktionsdaten auf Stundenbasis und kombiniert mehrere Signalklassen:

Strukturelle Muster sind stabil und vorhersagbar: Montags kommen die Wochenend-Abhebungen nach, Freitags wird für das Wochenende vorgesorgt. Monatszahltage haben ausgeprägte Spitzen. Lohnzahltage sind für Standorte nahe Industriebetrieben oder Einzelhandel anders als für Stadtzentrums-ATMs.

Kalendarische Ereignisse sind der wichtigste Differenzierungsfaktor gegenüber einfacher Trendextrapolation: Feiertage, Stadtfeste, Konzerte, Märkte, Sportveranstaltungen, Schulferien. Diese Ereignisse sind im Voraus bekannt — der Veranstaltungskalender ist die wichtigste externe Datenquelle für die Prognose.

Wetterkorrelationen sind standortspezifisch: Ein Innenstadt-ATM neben einem Wochenmarkt hat bei schönem Wetter höhere Abhebungen. Ein ATM in einer überdachten Einkaufspassage kaum.

Technisch setzt sich das beste Modell für diesen Use Case in der Praxis typischerweise aus einem Gradient-Boosting-Verfahren (XGBoost oder LightGBM) oder einem kombinierten SARIMA+ML-Ansatz zusammen — wie Suder, Gurgul et al. (2024) in ihrer Analyse von 61 ATMs in Polen zeigen konnten. XGBoost lieferte in stabilen Marktsituationen die besten Ergebnisse; bei starken externen Schocks schlug SARIMA die ML-Modelle. Der Schluss daraus: Ein robustes System sollte beide Ansätze kombinieren oder das dominante Modell anhand von Drift-Signalen wechseln können.

Das Ergebnis ist kein einzelner Vorhersagewert, sondern eine Prognose-Bandbreite mit Konfidenzintervall pro Automat — ergänzt um eine Prioritätsliste: “Diese 8 Automaten sollten in den nächsten 48 Stunden befüllt werden.” Der CIT-Dienstleister erhält eine optimierte Route statt einer festen Wochentour.

Asymmetrie der Fehler: Warum Leerstand zehnmal teurer ist als eine frühe Befüllung

Dieser Abschnitt ist der Kern des gesamten Projekts — und der am häufigsten unterschätzte.

Stell dir zwei Fehlerszenarien vor:

Szenario A — Zu früh befüllt: Das Modell prognostiziert, dass Automat 12 in 36 Stunden leerläuft. Der CIT-Fahrer kommt daher heute — obwohl der Automat noch 25 Prozent Füllstand hat. Kosten: Eine Befüllungsfahrt (90–150 EUR) plus das gebundene Kapital für die nächsten Tage.

Szenario B — Leerstand Freitagabend: Das Modell prognostiziert zu konservativ. Automat 12 läuft um 22:30 Uhr leer, als noch 60 Personen nach dem Konzert Bargeld brauchen. Kosten: Nicht nur der entgangene Service-Umsatz. Sondern Beschwerden, Kundenverlust an Wettbewerber, BaFin-relevanter Serviceausfall, Reputationsschaden — und bei größeren Instituten die Pflicht zur Berichterstattung nach § 25a KWG (Operational Risk Management).

Diese beiden Szenarien sind nicht symmetrisch. Szenario A kostet 90–150 EUR. Szenario B kostet ein Vielfaches davon — in direkten Kosten, Kundenschäden und Reputationseffekten.

Ein Standard-ML-Modell, das auf minimalen mittleren quadratischen Fehler (MSE) optimiert wird, behandelt beide Fehler gleich. Es ist ihm egal, ob es nach oben oder nach unten irrt — solange der durchschnittliche Fehler klein ist. Das ist für diesen Anwendungsfall das falsche Ziel.

Das richtige Ziel ist eine asymmetrische Verlustfunktion: Unterschätzung des Bedarfs (führt zu Leerstand) wird stärker bestraft als Überschätzung (führt zu frühzeitiger Befüllung). Konkret: Du definierst, dass ein prognostizierter Leerstand 8–12 mal so viel “kostet” wie eine überflüssige Fahrt. Das Modell lernt dadurch, lieber zu früh zu befüllen als zu spät.

In der Praxis bedeutet das:

• Das Konfidenzintervall wird asymmetrisch: Der Befüllauftrag wird ausgelöst, wenn das obere Ende des Verbrauchsintervalls plus einen Puffer in den “kritischen Bereich” fällt.
• Das System lernt explizit, welche Standorte besonders risikobehaftet sind (Innenstadt, Frequenz-Peaks, wenige Alternativen in der Umgebung) — und behandelt diese konservativ.
• Für jeden Automaten wird eine standortspezifische Asymmetrie definiert: Ein Automat in der Sparbüro-Filiale mit backup durch eine Servicekraft am Schalter hat eine andere Asymmetrie als der einzige ATM in einem 5-km-Radius.

Wer diesen Schritt überspringt und das Modell auf MAPE-Minimierung optimiert, hat ein System, das statistisch gut aussieht — aber operativ die falschen Entscheidungen trifft.

Konkrete Werkzeuge — was wann passt

Die Werkzeugwahl hängt stark davon ab, ob eine Python-basierte Eigenentwicklung möglich ist oder ob eine gemangte Cloud-Plattform bevorzugt wird.

scikit-learn + XGBoost (Python, open source) — Die pragmatischste Einstiegsoption für Teams mit Data-Science-Kompetenz. Gradient-Boosting-Modelle (XGBoost, LightGBM) auf tabellarischen Zeitreihendaten sind erprobt und liefern in Benchmarks konsistent gute Ergebnisse für ATM-Forecasting. Kostenlos. Volle Kontrolle über Modellarchitektur und Datenhaltung. Erfordert Python-Know-how und Infrastruktur für Deployment und Monitoring. Geeignet für Banken mit internem Data-Science-Team.

Azure Machine Learning (Microsoft Cloud) — Managed ML-Plattform für Teams, die Microsoft-Infrastruktur nutzen. AutoML unterstützt Zeitreihen-Forecasting direkt; keine eigene Infrastruktur nötig. EU-Datenhaltung (Frankfurt) möglich. Kosten: typisch 100–500 EUR/Monat für Training und Inference. Praktisch für Institute, die bereits Azure Active Directory und Microsoft 365 einsetzen — Zugriffsrechte und AVV sind dadurch vereinfacht.

Amazon SageMaker — Alternative für AWS-zentrische Häuser. Ähnliche Mächtigkeit wie Azure ML. Enthält fertige Algorithmen für Zeitreihen-Forecasting (DeepAR, AutoGluon-TimeSeries). EU-Hosting in Frankfurt möglich. Kosten strukturell ähnlich wie Azure ML.

Databricks — Wenn die ATM-Transaktionsdaten bereits in einem Data Warehouse oder Data Lake liegen, ist Databricks für das ML-Training und die Feature-Pipeline ideal. Besonders geeignet für Netzwerke mit über 100 ATMs, wo Datenmenge und Pipeline-Komplexität steigen. EU-Regionen verfügbar.

MLflow — Open-Source-Plattform für Model Management: Welches Modell läuft gerade in Produktion? Wann wurde es zuletzt retrained? Welche Versionsänderungen gab es? Für einen regulierten Bankbetrieb ist das keine optionale Ergänzung, sondern Pflicht — § 25a KWG verlangt nachvollziehbare Prozesse im operativen Risikomanagement. MLflow läuft selbst-gehostet oder auf Databricks.

Power BI — Für das laufende Monitoring: Wie viele Leerstand-Events gab es diese Woche? Welche Standorte haben das größte Forecast-Error? Wo weicht das Modell systematisch ab? Ein einfaches Dashboard auf Basis der Forecast-vs-Actual-Daten ersetzt aufwendige manuelle Berichterstellung.

Zusammenfassung: Wann welcher Ansatz

• Internes Data-Science-Team vorhanden → scikit-learn + XGBoost, MLflow selbst-gehostet
• Microsoft-Shop, kein Python-Team → Azure Machine Learning AutoML
• AWS-Infrastruktur → Amazon SageMaker mit DeepAR
• Großes Netz (über 100 ATMs), bestehender Data Lake → Databricks + MLflow
• Alle Szenarien → Power BI für Monitoring

Datenschutz und Datenhaltung

ATM-Transaktionsdaten enthalten auf den ersten Blick keine personenbezogenen Daten: Das System weiß, wann wie viel Geld abgehoben wurde — aber nicht von wem. De facto sind die Daten jedoch nicht trivial: In Kombination mit Zeitstempel und Karteninformationen aus dem Core Banking System könnte ein Angreifer Bewegungsprofile rekonstruieren. Für das Prognosemodell selbst genügen jedoch aggregierte Stunden-Summen pro ATM — ohne Kartennummern oder individuelle Transaktionsdetails.

Empfehlung: Das ML-Modell sollte ausschließlich auf aggregierten Zeitreihendaten trainiert werden (Betrag pro Stunde, nicht Einzel-Transaktion). Damit sinkt das DSGVO-Risiko erheblich, ohne die Prognosequalität zu beeinträchtigen.

Für die Wahl der Infrastruktur gilt:

• On-premise oder private Cloud: Höchste Kontrolle, keine Drittland-Transfers, DSGVO-konform per se. Empfohlen für Institute unter BaFin-Aufsicht mit strengen IT-Richtlinien.
• Azure Machine Learning (EU-Region Frankfurt): EU-Datenhaltung nachweisbar, Microsoft DSGVO-Addendum verfügbar, BSI-Grundschutz-Referenz für Microsoft Cloud vorhanden. Für viele Sparkassen und Volksbanken der pragmatischste Weg.
• Amazon SageMaker (EU-Region Frankfurt): Gleichwertige EU-Datenhaltung, AWS-Auftragsverarbeitungsvertrag (AVV) abrufbar.

§ 25a KWG — Operationelles Risikomanagement: KI-Modelle, die ATM-Betriebsabläufe steuern, fallen unter die Pflicht zur dokumentierten Risikosteuerung. Das bedeutet: Modell-Versionierung, Audit-Trail für Befüllentscheidungen, Eskalationsprozess bei Modellausfällen und Retraining-Protokoll. MLflow deckt die technische Dokumentationsseite ab; die prozessuale Einbindung muss das Institut selbst definieren.

AVV-Pflicht: Jeder Cloud-Anbieter, der Daten im Auftrag verarbeitet, benötigt einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO. Bei Azure, AWS und Databricks sind AVV-Templates verfügbar — aktiv anfordern und unterzeichnen lassen, bevor produktive Daten in die Cloud wandern.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

Der größte Aufwand liegt nicht in der Software, sondern in der Datenaufbereitung:

• Extraktion und Bereinigung historischer ATM-Transaktionsdaten (mindestens 18–24 Monate, stündliche Granularität): 3–6 Wochen Aufwand intern oder mit externem Datenbüro
• Aufbau der Feature-Pipeline (Veranstaltungskalender, Feiertage, Wetterdaten): 2–4 Wochen
• Modellentwicklung, Training, Validierung: 3–6 Wochen
• Pilotbetrieb mit 10–20 ATMs, Feinjustierung der asymmetrischen Verlustfunktion: 4–6 Wochen

Externe Dienstleister für ML-Projekte dieser Art berechnen in Deutschland typisch 40.000–120.000 EUR für Entwicklung und Einführung, abhängig von Netzgröße und Datenqualität. Für den Eigenaufbau mit vorhandenem Data-Science-Team rechne mit 2–4 Personalmonaten.

Laufende Kosten (monatlich)

• Cloud-Infrastruktur (Azure ML oder SageMaker, EU-Region): 300–800 EUR/Monat für Training und Inference (100–300 ATMs)
• MLflow Hosting (self-hosted): 100–300 EUR/Monat Infrastruktur
• Modell-Monitoring und Retraining: ca. 0,5–1 Tag Aufwand/Monat

Was du dagegenrechnen kannst

Konservatives Szenario für ein Netz mit 100 ATMs:

• CIT-Kosteneinsparung: 15 Prozent weniger Fahrten bei 250 Fahrten/Monat à 120 EUR = 4.500 EUR/Monat
• Working-Capital-Entlastung: 10 Prozent weniger Puffer bei 100 ATMs × 30.000 EUR Befüllvolumen × 5 Prozent Zinssatz = 1.250 EUR/Monat
• Leerstand-Vermeidung (3 Events/Monat à 500 EUR direkter + indirekter Schaden): 1.500 EUR/Monat

Konservative Gesamteinsparung: 7.250 EUR/Monat — also rund 87.000 EUR/Jahr.

Bei Entwicklungskosten von 60.000 EUR und laufenden Kosten von 500 EUR/Monat ist das Amortisation in unter 9 Monaten — konservativ gerechnet, ohne den Reputationseffekt.

ROI messen — so geht es wirklich
Die Messung ist direkter als bei fast jedem anderen KI-Anwendungsfall: Vor und nach Einführung zählst du Leerstand-Events, CIT-Fahrten und durchschnittlichen ATM-Füllstand. Die Differenz ist der Nutzen. Wenn das System gut ist, sieht man das in der CIT-Abrechnung des nächsten Quartals.

Drei typische Einstiegsfehler

1. Das Modell auf minimalen Vorhersagefehler optimieren, nicht auf minimale Kosten.
MSE und MAPE sind bequeme Metriken. Aber ein Modell, das auf diese Metriken optimiert, behandelt Leerstand und überflüssige Fahrt als gleichwertige Fehler. Sie sind es nicht — wie der Abschnitt zur Fehlerasymmetrie zeigt. Lösung: Die asymmetrische Verlustfunktion von Anfang an definieren. Definiere, wie teuer ein Leerstand-Event im Verhältnis zu einer überflüssigen Fahrt ist — und baue das in die Optimierungsfunktion ein, bevor du das erste Modell trainierst.

2. Das Modell zu selten retrainieren.
ATM-Nutzungsmuster sind nicht stabil. Neue Wohngebiete, veränderte Einzelhandelslandschaft, Pandemie-Nachwirkungen, neue Wettbewerber-ATMs in der Nähe — all das verändert die Nachfrage. Fallahtafti et al. (2022) dokumentierten, wie der COVID-19-Beginn die Vorhersagegenauigkeit von ML-Modellen schlagartig verschlechterte, während SARIMA-Modelle robuster blieben. Das ist kein Argument gegen ML, sondern ein Argument für geplantes Retraining: mindestens vierteljährlich, und immer nach identifizierbaren Schocks (Filialschließung, neue S-Bahn-Station, verändertes Filialnetz). Wer das Modell einmalig trainiert und dann vergisst, hat nach 18 Monaten ein System, das systematisch falsch liegt.

3. Zu viele ATMs auf einmal einführen.
Der Reflex: Alle 200 Automaten gleichzeitig umstellen — dann amortisiert es sich schneller. In der Praxis ist das riskant: Wenn das Modell für einen unbekannten Standorttyp systematisch schlecht funktioniert, merkst du das nur langsam. Lösung: Mit 10–20 ATMs starten, die eine repräsentative Mischung aus Standorttypen abdecken. Vier Wochen lang die Forecasts mit den tatsächlichen Abhebungen vergleichen, bevor ein CIT-Trigger ausgelöst wird. Erst nach validierter Genauigkeit auf das Gesamtnetz ausrollen.

Was mit der Einführung wirklich passiert — und was nicht

Das Modell ist das Einfachste an diesem Projekt. Die größere Hürde ist die Veränderung des operativen Prozesses.

Der CIT-Dienstleister hat feste Routen. Und das aus gutem Grund: Panzerfahrzeuge werden nicht am Vortag gebucht. Die meisten CIT-Verträge sehen ein festes Serviceintervall vor — Dienstag, Donnerstag, Freitag, Standort-X. Wenn du auf ML-basierte Bedarfsprognosen umstellen willst, muss der Vertrag das hergeben. Das bedeutet: Vertragsgespräch führen, bevor das Modell fertig ist. Einige CIT-Anbieter bieten inzwischen flexible Dispatch-Modelle an; andere nicht. Wer das erst nach der Entwicklung herausfindet, hat ein Modell ohne operativen Hebel.

Das Treasury-Team braucht einen neuen Workflow. Bisher war die Aufgabe: “Stimmt der Befüllplan noch?” Künftig ist sie: “Was sagt das System, und sehe ich einen Grund, davon abzuweichen?” Das ist eine andere mentale Haltung — und erfordert Vertrauen ins Modell, das sich erst durch Monate guter Vorhersagen aufbaut. Wer das Modell einführt und gleichzeitig erwartet, dass die Treasury-Mitarbeitenden sofort alle Entscheidungen delegieren, wird enttäuscht. Plane 3–4 Monate Parallelphase ein, in der die Forecasts sichtbar, aber noch nicht vollständig handlungsleitend sind.

Das erste Mal, wenn das Modell falsch liegt, wird wichtig. Irgendwann macht das System einen Fehler — eine unvorhergesehene Nachfragespitze, ein Ereignis, das nicht im Kalender stand. Wie das Institut darauf reagiert, entscheidet über die langfristige Akzeptanz. Eskalationsprozess definieren: Was passiert, wenn ein Automat unvorhergesehen unter 15 Prozent Füllstand fällt? Gibt es eine Notfall-Route? Sind die Parameter bekannt? Diese Fragen müssen beantwortet sein, bevor das Modell in Betrieb geht — nicht danach.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

“Wir füllen einfach mehr rein — dann gibt’s keine Leerstände.”
Das funktioniert. Bis zu einem Punkt. Der Punkt ist das gebundene Kapital. Bei 100 ATMs und je 60.000 EUR Maximalfüllung hältst du 6 Millionen Euro in Automaten — Kapital, das keine Rendite erzeugt, versichert und bewacht werden muss. Bei 5 Prozent Zinsniveau sind das 300.000 EUR Opportunitätskosten pro Jahr, allein für die Überfüllungsstrategie. Das ist kein theoretisches Risiko, das ist bilanzierte Ineffizienz. Overfilling ist keine Strategie — es ist ein Aufwand, der wegoptimiert werden kann.

“Unsere CIT-Routen sind fest vertraglich — wir können nicht flexibel disponieren.”
Das ist ein realer Einwand, kein Vorwand. Wenn der CIT-Vertrag keine flexible Dispatch-Option vorsieht, muss das Gespräch mit dem Dienstleister geführt werden — vor dem ML-Projekt, nicht danach. Es gibt CIT-Anbieter, die inzwischen bedarfsbasierte Modelle anbieten. Und selbst innerhalb fester Routen lässt sich die Befüllmenge pro Besuch optimieren — das erfordert keine flexible Route, nur bessere Mengenvorgaben.

“Wir haben zu wenig historische Daten für ML.”
Mindestens 18–24 Monate Stunden-Transaktionsdaten pro ATM sind nötig, um Saisonalität, Feiertage und Jahreszyklen zuverlässig zu lernen. Wenn die Daten in dieser Granularität nicht vorliegen, lohnt sich der Aufwand erst, wenn sie aufgebaut wurden. In der Übergangsphase können statistische Modelle (SARIMA) als Interim-Lösung eingesetzt werden — die funktionieren mit weniger Daten, sind weniger präzise, aber besser als feste Intervalle.

Woran du merkst, dass das zu dir passt

• Du betreibst mindestens 30 Geldautomaten — darunter rechnet sich der Entwicklungsaufwand selten; manuelle Planung ist dann oft effizienter
• Deine Befüllintervalle sind heute fix oder weitgehend fix — Optimierungspotenzial entsteht erst, wenn du von der Ist-Situation abweichen könntest
• Du hast mindestens 18 Monate ATM-Transaktionsdaten auf Stundenbasis — ohne diese Datenbasis ist das Modell nicht trainierbar
• Dein CIT-Dienstleister ermöglicht flexible Disposition (oder ist bereit, das zu verhandeln) — ein Prognosemodell ohne flexible Befüllmöglichkeit ist nur halb nützlich
• Du hattest in den letzten 12 Monaten mindestens drei identifizierbare Leerstand-Events — das ist das klarste Signal, dass das Problem real und häufig genug ist, um es systematisch anzugehen
• Du hast oder kannst aufbauen: einen internen Data-Science-Ansprechpartner oder einen externen ML-Dienstleister — ein Prognosemodell für Zeitreihen ist kein Low-Code-Projekt

Wann es sich (noch) nicht lohnt — vier harte Ausschlusskriterien:

1. Unter 30 ATMs im Netz. Bei kleineren Netzwerken ist der manuelle Planungsaufwand überschaubar, und der ROI rechtfertigt den Entwicklungsaufwand nicht. Excel-basierte Forecasting-Tabellen mit Wochentag-Korrekturen reichen für diese Größenordnung.

2. Keine historischen Transaktionsdaten auf Stundenbasis. Wenn euer Core-Banking-System oder ATM-Management nur Tagessummen ausgibt, fehlt die Eingangsgröße für intraday-Muster. Das Modell kann dann keine Freitagabend-Spitze von einer Montagmorgen-Delle unterscheiden. Zuerst Dateninfrastruktur verbessern.

3. CIT-Routen sind fest vertraglich auf Jahresbasis eingefroren ohne Abweichungsmöglichkeit. Ein Prognosemodell, das keine operativen Konsequenzen hat, ist nutzlos. Die Befüllmenge ist in diesem Fall zumindest optimierbar — aber das Vollenspotenzial bleibt ungenutzt.

4. ATMs in komplett unvorhersehbaren Lagen (reine Eventautomaten ohne Baseline). Ein temporärer Automat auf einem einmaligen Festival hat keine historische Baseline. Für solche Standorte greift manuelle Schätzung besser als ein Modell, das auf nicht vorhandene Daten angewiesen ist.

Das kannst du heute noch tun

Als erste Maßnahme ohne Investitionsaufwand: Zieh für dein ATM-Netz die Leerstand-Events der letzten 12 Monate aus dem Core-Banking-System oder dem ATM-Management-System. Liste Datum, Uhrzeit und Standort. Dann übertrag diese Daten auf den Stadtveranstaltungskalender des gleichen Zeitraums.

In den meisten Netzwerken stimmten über 60 Prozent der Leerstand-Events mit vorhersehbaren Ereignissen überein — Stadtfeste, Konzerte, Fußballspiele, Feiertagsvorläufe. Das ist die stärkste Evidenz für ein Planungssystem, die du deiner Geschäftsführung vorlegen kannst: nicht ein Modell, sondern ein Muster, das du erkannt hast.

Für den nächsten Schritt — eine erste Datenbasis-Analyse — hilft dir dieser Prompt:

Quellen & Methodik

• Bundesbank-Zahlungsverkehrsstatistik 2024: Deutsche Bundesbank, „Zahlungsverhalten in Deutschland 2023” (Stand Dezember 2024). Daten: ca. 51.000 ATMs in Deutschland, 27 Besuche/Person/Jahr, Ø 253 EUR/Abhebung. URL: bundesbank.de
• 40 % Überschusskapital in ATMs: Fallahtafti A., Aghaaminiha M., Akbarghanadian S., Weckman G.R.: „Forecasting ATM Cash Demand Before and During the COVID-19 Pandemic Using an Extensive Evaluation of Statistical and Machine Learning Models.” In: SN Computer Science, Vol. 3, Nr. 164 (2022). URL: link.springer.com
• XGBoost vs. SARIMA bei ATM-Forecasting: Suder M., Gurgul H., Barbosa B., Machno A., Lach L.: „Effectiveness of ATM withdrawal forecasting methods under different market conditions.” In: Technological Forecasting and Social Change, Vol. 200 (März 2024). DOI: 10.1016/j.techfore.2023.123089
• Cash Management als 50 % der ATM-Betriebskosten: Diebold Nixdorf: „Optimize the Cost of Cash” (Blog, April 2026). URL: dieboldnixdorf.com
• Kostenstrukturen CIT, Working Capital: Eigene Erfahrungswerte aus ATM-Optimierungsprojekten und branchenüblichen CIT-Vertragsdaten für Deutschland (Stand April 2026)
• § 25a KWG (Operationelles Risikomanagement): Kreditwesengesetz in der aktuell geltenden Fassung; BaFin-Rundschreiben zu MaRisk AT 4.3 (Risikotragfähigkeit und Risikosteuerung)
• Art. 28 DSGVO (AVV): Datenschutz-Grundverordnung in der aktuell gültigen Fassung

Du willst wissen, wie sich das konkret für dein ATM-Netz rechnen würde, welche Dateninfrastruktur du brauchst und ob der CIT-Dienstleister mitspielt? Meld dich — das klären wir in einem kurzen Gespräch.