Data Panda reads the CODA, MT940 and CAMT.053 files your banks drop on SFTP, in a mailbox or in your e-banking download folder, and lands every line in your warehouse next to invoices, payouts and ledger entries. From one place, we turn raw bank lines into dashboards, automations, AI workflows and custom apps your finance team uses every day.
Most companies still receive at least one bank-statement file the old way. CODA is the Belgian standard, maintained by Febelfin (the federation of the Belgian financial sector), and every Belgian bank publishes it daily for corporate clients. MT940 is the SWIFT end-of-day statement that banks across Europe and beyond have used for decades, and CAMT.053 is its ISO 20022 XML successor. The SWIFT migration to ISO 20022 for cross-border payment instructions completed on 22 November 2025, so CAMT.053 is the format you see growing fastest in 2026, while CODA and MT940 stay alive for domestic feeds and legacy contracts.
The connector reads those files wherever the bank drops them: SFTP folder, EBICS endpoint, an inbox the bank emails to, or an upload screen for the smaller account where a controller still pulls the statement by hand once a week. We parse the file shape (fixed-width for CODA, MT-syntax blocks for MT940, XML for CAMT.053), keep the IBAN, value date, booking date, amount, counterparty name, end-to-end reference and bank transaction code on each line, and land it in the warehouse against the customer or supplier the line is about. That is where daily cash position, AR and AP reconciliation, and fraud-volume monitoring live, instead of inside a dashboard one bank gives you for one account.
One picture of cash across every bank, every IBAN, every currency, refreshed the morning the file arrives.
Each booked bank line lands against the invoice, payout or expense it belongs to without a controller doing the matching.
Use the bank lines and their history to score risk and explain anomalies in plain language.
Internal tools around the bank lines for people who do not have a bank login.
A list of concrete reports, automations and AI features we have built on Bank Transactions data. Pick the one that matches your situation.
What is our group cash position right now, across every bank?
Closing balance per IBAN from the last booked file, summed by entity, bank and currency, with the file timestamp shown next to each account. The CFO sees the real number for the group instead of logging into four bank portals and adding them up in a spreadsheet.
How much of our incoming bank traffic gets matched to an invoice without a controller touching it?
The match rate per bank, broken down by structured reference (OGM-VCS or ISO 11649), amount-and-counterparty fallback, and the genuine unknowns. Trended monthly so you see whether discipline on the invoice template is working, and which customer keeps paying without quoting the reference.
Are we seeing payment patterns we should question before they become a fraud case?
Outgoing debits ranked against your own baseline for that counterparty, amount band and weekday, with the suspicious lines flagged for treasury review. Catches the new supplier paid on the same day they were created, the round-number payment to an unfamiliar IBAN, and the spike in payroll volume that should not have happened.
The CFO and the group controller get the actual cash position the morning the bank files arrive, across every entity and bank. Month-end close stops being the moment you discover one bank account drifted, because the warehouse already showed the gap on day three.
Sales sees which big customers cleared, on which IBAN and against which invoice, the morning after the wire arrived. Account managers stop chasing customers that already paid yesterday, and pipeline calls reflect cash, no longer only accrued revenue.
Operations and treasury get a single feed of every bank line across every account, with file-arrival monitoring and a fraud-review queue. The team that used to download CODA, MT940 and CAMT.053 by hand can spend that time on exceptions instead of routine pulls.
Incoming credit lines from CODA, MT940 or CAMT.053 land against open AR invoices in Exact Online on structured reference first, amount and counterparty as fallback. Outgoing debits clear AP invoices the same way. The accountant opens the queue with only the genuine unknowns left, instead of scrolling through every bank line that already had a match.
For Belgian SMEs running their accounting in Octopus, the daily CODA file gets parsed and pushed against open customer invoices using the OGM-VCS structured reference. Supplier payments clear AP the same morning. The bookkeeper sees a clean reconciliation at the start of the day, with the few unmatched lines surfaced as a short queue.
Yuki accounts that rely on a bank where the API feed lags or is missing get the same booked lines from the CODA, MT940 or CAMT.053 file the bank still drops daily. The Yuki ledger stays current, AR-AP reconciliation runs on time, and the accountant does not have to choose between waiting on the bank-side integration or uploading statements by hand.
For accounting firms running clients in Silverfin, the parsed CODA, MT940 and CAMT.053 lines feed the bank reconciliation working paper directly: opening balance, movement, closing balance and the per-line detail behind it. Reviewers stop re-keying the bank section of the file at quarter close, and the partner sees the same numbers across every client portfolio.
CODA, MT940 and CAMT.053 lines land in Microsoft Dynamics 365 Business Central as bank account ledger entries against the right bank account card, with the structured reference, counterparty and value date kept on the entry. Customer and vendor payment matching runs on the back of that, so finance teams stop importing statements per legal entity through the standard import wizard.
When a CODA, MT940 or CAMT.053 credit line clears against a HubSpot deal or company, the deal moves to closed-won-and-paid and the account owner sees the cash hit on the record. Sales stops chasing customers that already paid, and the renewal motion uses real cash dates, not invoice dates.
These are the 2 tables we currently pull from Bank Transactions into your warehouse. Query them directly in SQL, join them to the rest of your stack, or build reports on top.
Missing a table you need? We can extend the sync. Tell us what is missing and we will build it for you.
You keep the reporting tool you already have. We connect it to the warehouse where your Bank Transactions data lives.
OAuth authentication. Read-only by default. We sign a DPA and your admin keeps the keys.
Data flows into your warehouse on your schedule. Near real time or nightly, your call. You own the data.
We build the first dashboard, workflow or AI feature with you, then hand over the keys. Or we stay on for ongoing delivery.
We set up the foundation. Your team builds on top.
Best fit Teams that already have a BI analyst or data engineer and want to own the build.
We build the whole thing, end to end.
Best fit Teams without in-house BI or dev capacity. You tell us what you need and we deliver it.
You do. It lands in your warehouse, on your cloud account. We don't resell or aggregate it. If you stop working with us, the warehouse stays yours and keeps running.
Near real time for most operational systems. For heavier sources we schedule hourly or nightly. You pick based on what the reports need.
No. If you don't have one, we help you pick one and set it up as part of the first delivery. Common starting points are Snowflake, Microsoft Fabric, or a small Postgres start.
CODA (the Belgian Febelfin standard, current spec is version 2.7), MT940 (the SWIFT MT end-of-day statement most European banks still publish), and CAMT.053 (the ISO 20022 XML statement, with the camt.053.001.02 through camt.053.001.11 variants in active use). One file source can deliver multiple formats; we route each file to the right parser by extension and content sniff, so a mailbox or SFTP folder that mixes them needs no extra setup on your end.
Pick whichever channel the bank already uses with you: SFTP folder the bank writes to overnight, EBICS endpoint, an inbox the bank emails statements to, or a manual upload screen for a smaller account where someone still pulls the file by hand. The warehouse-side processing is the same; only the file-collection step differs per bank.
Open-banking APIs cover a slice of accounts and a slice of banks well, and a long tail of legacy banks, sub-accounts and corporate-only accounts not at all. The file feed is the catch-all for the rest: it works on every IBAN your bank cares to publish a statement for, including the foreign sub-account, the trust account and the historical archive. Most groups end up running both, with file feeds covering the gaps the API does not.
We review your Bank Transactions setup and the systems around it. Together we pick the first thing worth building.