Compliance posture for a cross-border consumer-lending network
Running a single GDPR programme across seven countries — and three regulator personalities — sounds like a checklist exercise. It is not.
The European GDPR is one regulation, applied in twenty-seven national contexts, with twenty-seven supervisory authorities, all of whom have slightly different views on what "explicit consent" means in the context of consumer credit.
If you operate across multiple of those jurisdictions, like we do, you can either run separate programmes per market — or you can find the highest common denominator and apply it everywhere. We chose the latter.
What that looks like in practice
Consent UI is identical across markets. The wording is translated, the mechanics are the same. Layered, opt-in, with explicit purpose. No pre- ticked boxes anywhere, even in markets that technically allow them.
Audit log granularity is set by the strictest regulator. The Dutch
DPA has been the most active in scrutinizing financial-services consent
mechanics; we apply their granularity expectations everywhere. If the
Danish regulator never asks for form_version_seen_at_consent_time, the
field still gets logged. Cost is trivial; gain is real.
Sub-processors are evaluated on the strictest data-residency standard. Some markets allow more permissive transfers; we don't make use of that slack. EU-resident only, full stop.
Deletion windows are set to the shortest legal requirement. Some markets allow 36 months for retained applicant data; we keep it for 24 unless the lender legally needs more for their own record-keeping.
Why that's not just compliance theater
Two reasons.
First: regulator confidence is durable. If we ever face questions in one market about how we handle data, the answer is "exactly the same way we handle it in your strictest peer's market." That answer is a lot faster than reconstructing what we did three years ago.
Second: partner sales cycles get shorter. When a lender asks for a DPA, they don't want to negotiate seven flavors. They want one document that meets their requirements. Standardizing upward means the DPA we hand them is already strict enough.
What we do per-market
Three things are unavoidably per-market and we don't try to standardize them:
- Cooling-off rules — different consumer-credit cooling-off periods per country.
- Pre-contract information requirements — what the applicant must see before they sign.
- Local language — translation accuracy by native speakers, not LLM.
Everything else is identical across markets and tested against the strictest regulator's published guidance.
What we'd do differently
If we were starting today, we'd build the audit log first and the routing engine second. Most of our retrofits in years 2–4 were about adding audit fields we should have captured from day one. Logging is cheap, deletion is easy; not having a record when a regulator asks is expensive.