Data Processing Agreement (DPA)

Last updated: October 6, 2026 · Version 1.6

Revision 1.6 (October 6, 2026): completes the agreement where art. 28 GDPR requires it. Clause 2 now says that the Processor informs the Controller immediately if, in its opinion, an instruction infringes data protection law. Clause 5 now says that each sub-processor is bound by a written contract to data protection obligations no less protective than this DPA (art. 28(4) GDPR), and that a new sub-processor is announced at least 30 days ahead by e-mail to the address of each active key, as well as in the changelog. Clause 6 states more precisely where the API and the website's functions process submitted identifiers. Clause 7 now provides for audits, including an inspection, once per calendar year at most and on 30 days' notice, where the documents are not sufficient. The new Clause 4.8 describes the backups of the account state, which already exist; Clause 8 and Annex I.6 say how long a deleted e-mail address can remain in them, and Infomaniak's role now includes them. The new Annex II lists each sub-processor with its role, its region, whether it can receive submitted identifiers, and the mechanism on which a transfer outside Switzerland and the EU/EEA relies. Version 1.6 only adds obligations on the Processor's side, or describes processing that already takes place, so it applies immediately to every Controller. A German courtesy translation is published; the English version prevails.

Revision 1.5 (October 5, 2026): Clauses 2, 4.2, 4.3 and 6 and Annex I now describe the processing as it already works, more precisely. For an invalid IBAN, at most the first 4 characters (country code and check digits) are kept, not 12. The network edge of our API host keeps the raw IP address and the path of each request for 7 days. The website's functions run in the Frankfurt region (EU). Clause 6 names the European Commission's adequacy decision for Switzerland, on which a transfer from the EU to the Processor relies. Nothing new is processed.

Revision 1.4 (September 27, 2026): Clauses 2, 4.2 and 7 and Annex I now describe the file audit: the annotated report it produces, which reproduces the columns of the uploaded file, is stored for at most 2 hours if unpaid and 24 hours after payment, then deleted. It describes the file audit as it already works; nothing new is collected.

Revision 1.3 (September 25, 2026): Clause 4.7 states when the relationship ends: it continues as long as a key is active; revoking the last key, or requesting it, ends it and starts the deletion period. It applies immediately to new customers and, from November 1, 2026, to customers who accepted an earlier revision.

Revision 1.2 (August 5, 2026): corrected the hosting region in Clauses 4.3 and 6 — processing runs in Railway's Amsterdam (EU) region, not Zurich; only Railway's network edge sits in Zurich. Sub-processor list completed and aligned with Privacy Policy §3 (AI drafting assistance, CI infrastructure). Clause 4.2 now states the one-time key delivery window. Retention clauses extended to every per-request table.

Revision 1.1 (July 11, 2026): telemetry attributable to a terminated customer is now deleted by default 30 days after termination — previously deletion was on request. See Clause 4.7 and Annex I.6.

This DPA supplements the Terms of Service and applies whenever a customer (« Controller ») uses the IBANforge API in a way that involves personal data — an IBAN can identify a natural person. It is offered as a standing, pre-signed agreement: by using the Service under a paid or free plan you may rely on it without countersignature; a countersigned PDF is available on request at support@ibanforge.com.

1. Roles and scope

• Controller: you, the customer embedding or calling the API.
• Processor: IBANforge, sole proprietorship established in Switzerland (Legal Notice).
• Subject matter: validation and enrichment of bank identifiers submitted by the Controller.
• Duration: as long as the Controller uses the Service.
• Nature and purpose: ephemeral, automated processing of submitted identifiers to return validation/enrichment results.
• Categories of data: bank account identifiers (IBANs) and, for account management, the Controller's contact email.
• Data subjects: the Controller's customers, suppliers, employees or end users whose IBANs are submitted.

2. Processing instructions

The Processor processes submitted data only to produce the API response (for the file audit, the report the Controller orders), and on no other instruction. IBANs submitted for validation are processed in memory and are not stored (sole exception: for invalid IBANs, at most the first 4 characters, the country code and check digits, may be retained up to 12 months for data-quality diagnostics). The file audit is a separate deliverable: when the Controller uploads a file to it, the annotated report produced, which reproduces the columns of the uploaded file, is stored for at most 2 hours if unpaid and 24 hours after payment, then deleted. The Processor does not use Controller data to train models, build marketing profiles, or enrich third-party datasets.

The Processor informs the Controller immediately if, in its opinion, an instruction infringes the GDPR, other Union or Member State data protection provisions, or the Swiss FADP.

3. Confidentiality and personnel

The Service is operated by its owner; no employees have access to production data. Any future personnel will be bound by written confidentiality before access.

4. Technical and organisational measures (TOMs)

• 4.1 Transport encryption (TLS) on all endpoints; HTTP redirected to HTTPS.
• 4.2 Data minimisation by design: no storage of IBANs submitted for validation (the file audit keeps only its report, for the periods in Annex I.6); IP addresses stored only as salted hashes in the Processor's own logs (the API host's network edge keeps the raw address and the request path for 7 days); API keys stored as hashes — a newly issued key is additionally held for one-time retrieval (cleared on first read, or after 7 days at the latest) and delivered to the customer by email.
• 4.3 Hosting in the Amsterdam (EU) region (Railway), with volume-level isolation and a Zurich network edge for Swiss traffic; the website's functions run in Vercel's Frankfurt (EU) region.
• 4.4 Request metadata automatically purged after 12 months at the latest.
• 4.5 Access to production restricted to the operator with strong authentication; secrets held in the hosting platform's secret store.
• 4.6 Public status page and monitored error rates.
• 4.7 Telemetry deletion after termination, by default: request metadata (telemetry) attributable to a customer's API keys is automatically deleted 30 days after termination of the agreement or deactivation of the customer's last key — without requiring a request. A key rotation does not trigger this deletion (the customer relationship continues). The relationship continues as long as a key is active; revoking your last key, or requesting it, ends the relationship and starts the deletion period. See Annex I.6.
• 4.8 Backup: the account state is backed up every night to a server of Infomaniak in Switzerland, which keeps 30 days of copies; monthly copies, the last three kept, are held on a computer operated by the Processor in Switzerland. The account state covers the API keys (as hashes) and the e-mail addresses attached to them, quotas, credit balances, monthly usage counts, purchase records (payment references, payer e-mail, and for USDC the paying wallet address and transaction hash), and the records of key creation, claim and revocation, with the salted IP hash and user-agent recorded for them. The restore is tested. Submitted identifiers and the request log are not part of the backups.

5. Sub-processors

The Controller authorises the sub-processors listed in the Privacy Policy §3 (Railway — Amsterdam (EU) hosting; Vercel — website & dashboard; Stripe — card payments; Coinbase CDP — USDC settlement, with the x402.org facilitator as fallback; Infomaniak — email and nightly backups; GitHub — public code & CI; Anthropic — AI-assisted drafting of correspondence). Changes are announced at least 30 days before a new sub-processor receives personal data, by e-mail to the address attached to each of the Controller's active keys and in the changelog (keys without an address: the changelog only); the Controller may object on reasonable grounds within that period, in which case either party may terminate.

The Processor engages a sub-processor only under a written contract that imposes on it data protection obligations no less protective than those set out in this DPA, in particular sufficient guarantees to implement appropriate technical and organisational measures in such a manner that the processing meets the requirements of the GDPR, as art. 28(4) GDPR provides. Annex II lists each sub-processor, its role and region, whether it can receive submitted identifiers, and the transfer mechanism it relies on.

6. International transfers

The API processes submitted identifiers in Railway's Amsterdam region (Netherlands), and the website's functions process those relayed from the playground and the dashboard in Vercel's Frankfurt region (Germany). For Controllers subject to the GDPR, transfers to the Processor, established in Switzerland, rely on the European Commission's adequacy decision for Switzerland (Decision 2000/518/EC, confirmed by the Commission's review of 15 January 2024); no standard contractual clauses are needed. For Swiss Controllers, Swiss law recognises the EU as adequate. Where a sub-processor operates from a third country, transfers rely on adequacy decisions (including the EU-US and Swiss-US Data Privacy Framework for certified US sub-processors) or the sub-processor's standard contractual clauses. Annex II states the mechanism for each sub-processor and which of them can receive submitted identifiers.

7. Assistance, incidents, audits

• Data subject requests: given that IBANs submitted for validation are not stored and file-audit reports are deleted within 24 hours of payment, the Processor typically holds no data to retrieve or erase; the Processor will nevertheless assist the Controller within 30 days for whatever is held (account email, request metadata).
• Personal data breach: notification to the Controller without undue delay and within 72 hours of becoming aware, with the information required by art. 33(3) GDPR.
• Audit: the Processor makes available to the Controller all information necessary to demonstrate compliance with art. 28 GDPR (this DPA, the Privacy Policy, a description of the architecture and of the technical and organisational measures) and answers reasonable written audit questions. Where that information is not sufficient, or where a supervisory authority requires it, the Controller, or an auditor it mandates who is bound by confidentiality, may carry out an audit, including an inspection, once per calendar year at most, on at least 30 days' written notice, during Swiss business hours, at the Controller's expense, and without access to the data of other customers. The Processor contributes to such audits.

8. Deletion and end of service

On termination, telemetry attributable to the Controller's keys is deleted by default 30 days after termination (Clause 4.7); the Controller's account record (email, hashed key) is deleted from the live record on request, and backups that still hold it age out within 90 days, subject to statutory bookkeeping duties for billing records. There is no stored IBAN corpus to return or delete.

9. Liability and law

Liability follows the Terms of Service §8. This DPA is governed by Swiss law; for Controllers subject to the GDPR it is to be interpreted in conformity with art. 28 GDPR.

Contact for all DPA matters: support@ibanforge.com

---

Annex I — Description of the processing

• I.1 Subject matter: validation and enrichment of bank identifiers (IBAN/BIC) submitted by the Controller through the API; for the file audit, checking a file uploaded by the Controller and producing its annotated report.
• I.2 Data subjects: the Controller's customers, suppliers, employees or end users whose IBANs are submitted.
• I.3 Categories of personal data: bank account identifiers (IBANs) and BICs in transit; for the file audit, the columns of the uploaded file (for example payee names and addresses); the Controller's contact email for account management; request metadata (endpoint, timestamp, status, latency, salted IP hash, API-key prefix); in the API host's network edge log, the raw IP address and the request path, for 7 days.
• I.4 Special categories: none.
• I.5 Processing operations: ephemeral, automated in-memory validation/enrichment producing the API response; for the file audit, storage of the annotated report for the periods in I.6; aggregate service statistics without personal data.
• I.6 Retention: IBANs submitted for validation are not stored (sole exception: for invalid IBANs, at most the first 4 characters, the country code and check digits, up to 12 months for data-quality diagnostics). The file-audit report is kept at most 2 hours if unpaid and 24 hours after payment, then deleted. Request metadata (telemetry) is kept at most 12 months, and telemetry attributable to a terminated customer is deleted by default 30 days after termination (Clause 4.7). Backups of the account state are kept as described in Clause 4.8: 30 days of nightly copies, and monthly copies, the last three kept; a deleted e-mail address ages out of them within 90 days. Billing records are kept as required by statutory bookkeeping law.

Annex II — Sub-processors and transfer mechanisms

Data Privacy Framework (DPF) entries were checked on the official register, dataprivacyframework.gov, on October 5, 2026. "Both frameworks" means the EU-US Data Privacy Framework and the Swiss-US Data Privacy Framework.