Short answer
Reconciliation software security means protecting the bank statements, invoices and customer details the tool reads, and making every matching decision traceable. When you evaluate a tool, check its GDPR role and contract, data minimisation, tenant isolation, safe file parsing, formula-safe exports, audit trail, AI data handling and tested backups. Ask for evidence, not badges.
Why does a reconciliation tool need its own security review?
A reconciliation tool sees the same data as your bank account, plus your sales ledger. A typical bank statement line contains a payer's name, an IBAN, an amount, a date and free-text remittance information, which can include anything a customer typed. Invoices add addresses, contact persons and payment terms. Together they show who pays you, how much and how late.
That makes reconciliation software a natural target, and also a source of quieter risks: a crafted file that attacks the parser, an exported spreadsheet that runs a formula, a match that nobody can explain at year-end. The checklist below covers those risks in plain terms. It applies to any vendor, including us.
Which GDPR role does a reconciliation provider have?
The General Data Protection Regulation (GDPR, Regulation (EU) 2016/679) distinguishes two roles:
- A controller decides the purposes and means of processing personal data (Article 4(7)). When you reconcile your own customers' payments, you are normally the controller.
- A processor processes personal data on behalf of the controller (Article 4(8)). A software provider that hosts your statements and runs matching on your instructions is normally your processor.
The European Data Protection Board explains how to apply these concepts in its Guidelines 07/2020, final version of 7 July 2021. The role depends on the facts of each processing activity, not on what a contract calls it.
If the vendor is your processor, Article 28(3) requires a contract or other legal act. Among other things, the processor must:
- process data only on your documented instructions;
- ensure that staff are bound by confidentiality;
- take the security measures required by Article 32;
- engage sub-processors only with your prior authorisation (Article 28(2));
- delete or return all personal data at the end of the service, at your choice (point (g));
- make information available and allow audits (point (h)).
What to ask: a copy of the data processing agreement, the list of sub-processors (hosting, email, support tools, AI providers) and the locations where data is processed. Transfers to countries outside the EU are only allowed under the conditions of Chapter V (Article 44). Hosting in the EU does not by itself settle every question.
Security checklist for evaluating reconciliation software
| # | Control | Why it matters | What to ask the vendor | DIGITAL EUR status |
|---|---|---|---|---|
| 1 | GDPR role and contract | Defines who is responsible for what | DPA under Article 28, sub-processor list, transfer safeguards | PLANNED: role assessment and DPAs before any customer data |
| 2 | Data minimisation | Data not collected cannot leak | Which fields are required? Can unneeded columns be dropped on import? | Demo requires only ID, customer name, currency, amount, reference or remittance text and direction; IBAN is optional |
| 3 | Tenant isolation | One customer must never see another's data | Is isolation enforced on the server, on every query? Is it tested? | Engine refuses cross-tenant candidates; server-side enforcement PLANNED |
| 4 | Safe file import | Uploaded files are untrusted input | Size limits, type allowlists, behaviour on malformed rows | CSV up to 2 MB and 20,000 rows, strict validation, read in your browser |
| 5 | XML parsing (CAMT.053) | XML parsers can be abused through external entities | Are DTDs and external entities disabled? | No XML import yet; XXE-safe parsing PLANNED before CAMT.053 support |
| 6 | Formula-safe export | A CSV cell can run as a spreadsheet formula | How are cells starting with =, +, -, @ handled? | In place: such cells are prefixed and quoted |
| 7 | Audit trail | Every match must be explainable later | Who approved what, when and for how much? Can entries be edited? | In place in the demo: append-only events; persistent storage PLANNED |
| 8 | Access control | Stolen passwords are a common way in | MFA, session handling, roles for preparer and approver | PLANNED: secure sessions, CSRF protection, rate limiting, MFA-ready login |
| 9 | Encryption | Protects data on the network and on disk | In transit and at rest? Who manages the keys? | Public site over HTTPS; at-rest encryption PLANNED |
| 10 | Backups and restore | Backups only count if a restore has worked | Off-site? Encrypted? When was a restore last tested? | PLANNED: encrypted off-server backups with a tested restore |
| 11 | Retention and deletion | Old statements are a liability | How long is data kept? What happens when you leave? | PLANNED: written retention and deletion policy |
| 12 | Breach handling | The law sets deadlines | Incident procedure, how and when you are told | PLANNED: written breach procedure |
| 13 | AI data handling | Model providers become sub-processors | Is AI optional? What is sent? Is it used for training? | No AI features today; rules below |
| 14 | Testing | Controls drift without checks | Automated tests, external testing, disclosure contact | Matching and money handling covered by automated tests |
Rows marked PLANNED do not exist yet. They are the conditions we have set for ourselves before DIGITAL EUR accepts any customer data. That is also why accounts are not open.
What does GDPR Article 32 expect from a provider?
Article 32(1) asks controllers and processors to take technical and organisational measures appropriate to the risk. It lists examples:
- pseudonymisation and encryption of personal data;
- the ability to ensure the ongoing confidentiality, integrity, availability and resilience of systems;
- the ability to restore the availability of and access to personal data in a timely manner after an incident;
- a process for regularly testing, assessing and evaluating whether the measures work.
Point 3 is why the checklist asks when a restore was last tested, not just whether backups exist. Point 4 is why a security page should show dates.
The principles in Article 5 apply too. Data must be limited to what is necessary (data minimisation, Article 5(1)(c)) and kept no longer than necessary (storage limitation, Article 5(1)(e)). If a breach happens, the controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to people (Article 33(1)). A processor must inform the controller without undue delay (Article 33(2)). Where processing is likely to result in a high risk, the controller must carry out a data protection impact assessment beforehand (Article 35).
How does CSV formula injection work, and how does our export handle it?
Reconciliation tools export CSV files that people open in spreadsheet programs. If a cell starts with a character such as =, the program may treat the cell as a formula. A payer can put such text in the remittance information or the name field of a transfer. That text then travels through your bank statement and the reconciliation tool into a spreadsheet on your accountant's computer.
OWASP lists =, +, - and @, as well as tab, carriage return and line feed, as risky first characters. Its suggested mitigation is to prefix such cells with a single quote and to quote every field.
Our CSV export, used by the Reconciliation Lab today, works like this:
- a cell starting with
=,+,-,@, tab or carriage return gets a leading single quote; - a cell containing a comma, quote or line break, or with leading or trailing spaces, is wrapped in double quotes, and inner quotes are doubled;
- lines end with CRLF, following the common CSV convention.
Limits we want you to know about. OWASP notes that no CSV sanitisation works for every spreadsheet program. It also notes that some programs can remove the protection after a file is saved and reopened. Full-width variants of these characters may also behave like formulas in some locales, and our export does not rewrite them. A cell that starts with a line feed is quoted but not prefixed. Open exported files with care, and do not enable content in files whose source you do not trust.
Why does CAMT.053 import need XXE-safe parsing?
CAMT.053 is the ISO 20022 XML format many European banks use for account statements. XML has a feature called external entities, which lets a document refer to other files or addresses. If a parser resolves them, a crafted statement file could make the server read local files or send requests to internal systems. This is called XML External Entity (XXE) injection.
OWASP's main recommendation is to disable document type definitions (DTDs) completely wherever possible. Where they are needed, external entities and external DTD loading should be blocked. We plan to follow that recommendation when we add CAMT.053 import. Import also needs size limits, a file-type allowlist and idempotent processing, so a file uploaded twice is not counted twice.
The Reconciliation Lab does not accept XML today, so this risk does not exist in the demo yet.
What should a reconciliation audit trail record?
An audit trail answers one question months later: why is this invoice marked as paid? In the Reconciliation Lab, each decision creates an event with:
- a sequential event ID and an ISO timestamp;
- the actor who made the decision;
- the action: approve, reject, or reverse an approval and reject it;
- the invoice ID, the transaction ID and the amount in cents.
Events are append-only. Earlier entries are never changed or removed, and a reversal is recorded as a new event rather than an edit. Every allocation needs a person's approval, including exact matches. No allocation can exceed the invoice's outstanding amount or the transaction's remaining amount. In the demo the trail lives in your browser session. Durable storage of the same events is planned for real accounts.
When you evaluate any vendor, ask whether its log can be edited by administrators, whether it records rejected suggestions as well as approvals, and whether you can export it.
How should AI be handled when bank data is involved?
DIGITAL EUR does not use AI to match payments. Matching is deterministic: the same files always give the same suggestions and the same reason codes. If we add AI features later, for example to read invoice PDFs, these rules apply:
- AI is opt-in, and you can switch it off again.
- No raw statements, unmasked IBANs or customer personal data are sent to a model provider by default. Only the minimum fields are sent, with redaction where possible.
- A model provider is treated as a sub-processor, under a documented agreement and listed for customers.
- How long the provider keeps the data, and whether it may use it for anything else, is stated before the feature is switched on.
- AI output is a suggestion, never an approval. A person still decides.
Ask any vendor that advertises AI matching the same questions.
What is protected today, and what is not?
| Layer | Today | Before customer data |
|---|---|---|
| Public website | Static pages over HTTPS; no login | Responsible-disclosure contact published |
| Reconciliation Lab | Runs in your browser; your files are not uploaded to us; nothing is saved between sessions | Not applicable: the demo stays local |
| Accounts and stored data | Do not exist | Every PLANNED control in the checklist above |
We do not hold ISO 27001, SOC 2 or PCI DSS certification, and we do not describe our security as "bank-level". This page will be updated with a date when a planned control goes live. See what is real today for the operator details.
How do you run your own evaluation?
- Write down which data the tool will receive: which accounts, which fields and which customers.
- Decide the GDPR roles and request the data processing agreement and sub-processor list.
- Test imports with a deliberately broken file: wrong separator, an over-long row, an amount with a comma decimal. A good tool rejects the file clearly instead of guessing.
- Put
=1+1in a text field that appears in the export (in our Lab, the invoice ID), approve a match, export it and open the file in your spreadsheet program. - Approve one match, reverse it, and check that both events appear in the audit log.
- Ask when a backup restore was last tested and how long it took.
- Ask where AI is used and what is sent to the provider.
- Check how data is deleted when you leave, and get it in writing.
You can try steps 3 to 5 now in the Reconciliation Lab with sample files. Planned plan limits are on the pricing page.
Frequently asked questions
Is reconciliation software covered by GDPR?
Yes, whenever the files contain personal data. Payer names, IBANs of individuals and free-text references usually count. The business using the tool is normally the controller, and the vendor is normally a processor bound by an Article 28 contract.
Do I need a data processing agreement with my reconciliation vendor?
If the vendor processes personal data on your behalf, Article 28(3) requires a contract or other legal act with specific content, including sub-processor rules and deletion or return of data at the end.
Is a certification the same as being secure?
No. A certificate shows that an auditor checked defined controls within a defined scope at a defined time. Ask for the scope and date, and still ask the checklist questions. We hold no certification and do not claim one.
Can a bank statement file attack my computer?
A file cannot do anything until software reads it. A badly built parser or a spreadsheet that runs formulas can turn text in a file into an action. That is why imports need strict parsing and exports need formula protection.
Does the Reconciliation Lab send my files anywhere?
No. The demo reads files in your browser and has no server, database or login. Closing the tab discards the data.
Does DIGITAL EUR ever access my bank account?
No. We do not ask for bank logins, do not connect to bank accounts and never hold or move money. You export statements from your bank and choose what to import.
Sources
- EUR-Lex, Regulation (EU) 2016/679 (General Data Protection Regulation) (accessed 5 November 2026)
- Council of the EU, GDPR text adopted at first reading, document 5419/16 (PDF) (accessed 5 November 2026)
- European Data Protection Board, Guidelines 07/2020 on the concepts of controller and processor in the GDPR (accessed 5 November 2026)
- OWASP, CSV Injection (accessed 5 November 2026)
- OWASP Cheat Sheet Series, XML External Entity Prevention (accessed 5 November 2026)