Wofür das Modul gedacht ist
Banking-Integrationen ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Automatische Bank-Anbindungen und CSV-Importe verwalten, Importzeiträume steuern und Daten vor dem Import bereinigen. Im tenantweiten Kontext sorgt der Bereich dafür, dass wiederkehrende Entscheidungen, Stammdaten oder Übersichten nicht in Nebensysteme ausweichen müssen.
Banking-Integrationen ist als eigenständiger Produktbaustein gedacht. Gerade deshalb lohnt sich ein Blick darauf, wie der Bereich mit Rollen, Datenkontext und angrenzenden Modulen zusammenspielt.
Typische Einsatzfälle
Diese Situationen zeigen, wann der Bereich in einem sauberen Rollout oder im laufenden Betrieb konkret Mehrwert liefert.
Bankanbindungen kontrolliert starten
Neue Verbindungen lassen sich so aufsetzen, dass der erste Datenimport fachlich zum vorhandenen Bestand passt. Bei finAPI kann dafür direkt beim Verbinden ein Startdatum gesetzt werden.
CSV-Dateien vor dem Import bereinigen
Die serverseitige Arbeitsliste zeigt importierbare Zeilen, mögliche Duplikate und ungültige Datensätze, bevor Transaktionen endgültig gespeichert werden.
Importpfade sauber abstimmen
Automatische Synchronisation und manuelle Nachimporte bleiben nachvollziehbar, damit die Transaktionsbasis für Finanzen, Zahlungen und Prüfungen konsistent bleibt.
Wie das Modul mit anderen Bereichen zusammenspielt
struct-i-vio ist als zusammenhängende Plattform gedacht. Diese Module liegen fachlich am nächsten bei diesem Bereich.
Finmap Einstellungen
Finmap Einstellungen ergänzt Banking-Integrationen, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsTransaktionen
Transaktionen ergänzt Banking-Integrationen, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsProjekt-Zahlungen
Projekt-Zahlungen ergänzt Banking-Integrationen, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsBerechtigungen und Sichtbarkeit
Die öffentliche Dokumentation beschreibt die Logik auf Produktniveau - nicht als technische Policy-Liste, sondern als Rollout-Leitfaden.
Best Practices
So bleibt der Bereich bei Einführung und Nutzung anschlussfähig an den restlichen Produktfluss.
Entwickler Info
Empirisch erhobene Befunde aus Stage-2-Isolations-Probe inkl. 4-Schichten-Enforcement-Scan. Das Modul ist sauber durchgängig auf API-Layer gegated; die einzigen versteckten Kopplungen sind Cross-Module zu guv_transactions, weil die Daten am Ende in fact_transactions landen.
Entwickler-Info aufklappen (6)
view: API-Permission + RLS auf 8 Banking-Tabellen (defence in depth)
Das API-Gate steht in providers.ts:160 und an mehreren weiteren Endpoints. Zusätzlich liegen RLS-SELECT-Policies auf banking_provider_connections, csv_import_mappings, finapi_accounts, finapi_bank_connections, finapi_sync_log, finapi_users, gocardless_accounts und gocardless_requisitions. Verweigerung wirkt sofort als 403 (API), aber selbst bei API-Bypass würde RLS leere Listen zurückgeben.
pages/api/banking/providers.ts:160RLS: bpc_select, csv_map_select, finapi_acc_select, finapi_bc_select, finapi_sl_select, finapi_users_select, gc_acc_select, gc_req_select
manage: API-Permission + RLS auf alle Banking-Tabellen-Mutations
API-Pre-Check in csv/mappings.ts:21, providers.ts:237/278, gocardless/requisitions.ts:22, finapi/* (connect/callback/update/disconnect/sync/status/confirm-selection). RLS auf INSERT/UPDATE/DELETE der gleichen 8 Tabellen wie view. Standalone — keine Cross-Module-Coupling.
pages/api/banking/csv/mappings.ts:21pages/api/banking/providers.ts:237
⚠ KRITISCHModul hat keine eigene UI-Page — alle 4 Actions hängen am /guv/transactions-Tab
In dim_modules ist route=NULL. Die Banking-Provider-Konfiguration wird als Tab-Komponenten (FinmapSettings, GoCardlessSettings, FinapiSettings, CsvImportSettings) IM /guv/transactions-Page eingebettet. Diese Page ist gegated auf hasAccess('guv_transactions') — Modul-Visibility. Konsequenz: Wer banking_settings.* hat aber das guv_transactions-Modul nicht sehen darf, kommt nie an die Banking-UI. Der Backend-Permission-Toggle ist live, aber praktisch unerreichbar.
pages/guv/transactions.tsx:165 (hasAccess('guv_transactions') gate)pages/guv/transactions.tsx:19-23 (FinmapSettings/GoCardlessSettings/FinapiSettings/CsvImportSettings imports)dim_modules.banking_settings.route = NULL
⚠ KRITISCHsync: versteckte Cross-Module-Kopplung an guv_transactions.sync_transactions
Banking-Sync-Endpoints (sync-all.ts, gocardless/sync.ts, finapi/sync.ts) verwenden supabaseWithTenant (User-Kontext, RLS aktiv) und INSERTen abgerufene Transaktionen in fact_transactions. Die WITH_CHECK-Policy fact_transactions_insert verlangt guv_transactions.sync_transactions — ohne diese Permission scheitert die Insertion still im DB-Layer trotz erfolgreichem API-Permission-Check. Statisch entdeckt; im Probe wurde 200 zurückgegeben, weil kein Provider konfiguriert war (also keine Daten zum INSERTen). Im echten Betrieb tritt das Phänomen auf, sobald ein Provider tatsächlich Daten liefert.
pages/api/banking/sync-all.ts:27 (supabaseWithTenant)pages/api/banking/finapi/sync.ts:27pages/api/banking/gocardless/sync.ts:25lib/permission-dependencies.ts (cross_module conditional)
⚠ KRITISCHcsv_import: gleiche Cross-Module-Kopplung wie sync
pages/api/banking/csv/import.ts INSERTet die geparsten CSV-Zeilen als User-Kontext in fact_transactions. Gleiche RLS-Voraussetzung: guv_transactions.sync_transactions. Die /preview-Route allein triggert das Coupling NICHT (kein INSERT) — relevant ist nur der eigentliche Import.
pages/api/banking/csv/import.ts:153 (supabaseWithTenant) + :211 (fact_transactions Lookup)
Kein vestigialer Toggle, kein Backdoor
Alle 4 Actions sind effektiv durchgesetzt. Es gibt keine alternative SELECT-Policy, die die view-Permission umgeht (anders als bei guv_transactions, wo project_payments.view eine Teilsicht öffnet).