Data residency and compliance
Data residency and compliance for Stonewake describes where product data is hosted, Stonewake's rule that it never trains models on customer data, and how human confirmation sits over draft scores and verdicts. The public posture is EU and UK hosting for the product database and backend, no Stonewake model training on customer data, and transparency notices consistent with the EU AI Act.
Data residency and compliance posture at capability level
Stonewake's public privacy documentation states that the product database and backend run on infrastructure in the European Union and the United Kingdom, with data at rest held in Finland and the United Kingdom. The website and dashboard front end are delivered through a global edge network whose server functions run in the United States; that front-end delivery layer is a separate posture from where product data and the backend sit. Transfers to the United Kingdom rest on the European Commission's adequacy decision for the UK, reviewed and renewed in 2025 and valid to 27 December 2031.
This methodology page restates those commitments at capability level. It does not publish a subprocessor inventory, model-vendor list, or infrastructure diagram, and no such inventory is published elsewhere on the site today. Vendor due diligence on residency, including the contractual data processing terms described below, sits in the bank's own procurement process rather than in this methodology.
GDPR-oriented product design
Regulation (EU) 2016/679 (GDPR) sets the baseline for personal-data processing in the EEA and, via the UK regime, informs UK expectations under the adequacy arrangement described above. Stonewake's public compliance language for core screening surfaces describes organisations and countries as the screening subjects, with ownership chains that stop at an individual and say so, human review of drafts, and no automated decision producing legal effects by itself.
Key capability statements published by Stonewake and relevant to bank desks:
- Stonewake never trains models on customer data.
- Draft scores and verdicts require analyst confirmation before they are treated as final.
- Material verdicts land in an append-only audit ledger.
- Outputs are decision-support research artefacts, not credit scoring and not sanctions or PEP screening.
KYC, KYB, adverse media screening, and sanctions screening remain bank-owned control frameworks under this design. Stonewake's screening surfaces do not replace a bank's designated sanctions or PEP systems, and FATF-aligned national rules continue to govern the institution independently of the tooling.
EU AI Act transparency
Regulation (EU) 2024/1689 (the EU AI Act) includes transparency obligations for certain AI interactions under Article 50, covering disclosure that content is AI-generated or AI-assisted. Stonewake's public materials state that AI-drafted content is labelled in the product under this framing, that a self-assessment memo is available on request, and that the offering is positioned as decision support with a human in the loop rather than automated credit scoring or sanctions and PEP screening. This page does not reproduce that memo.
Human-in-the-loop design connects to the same posture described in deal book scoring, country risk composite, and adverse media screening: scores, composites, and verdicts are drafts for analyst confirmation, not final outputs.
What data residency and compliance does not cover
This methodology does not:
- disclose subprocessors, model vendors, or an infrastructure diagram beyond the residency posture stated above
- name customer banks or pilot references
- describe how to mine public registers for origination advantage
- assert that Stonewake is a certified substitute for a bank's AML programme
Mapping Stonewake's controller and processor roles onto a bank's own record of processing activities, and confirming retention, erasure, and audit export needs in contract schedules, is procurement and legal work that sits outside this public methodology page.
Fit to desk solutions
Residency and compliance questions typically surface beside commercial evaluations of export finance, project finance, and CRE origination tooling, alongside country risk and counterparty adverse media coverage for banks. The evidence discipline described in citations and evidence is part of the same control story: a customer-visible claim on this site is expected to be source-backed.
Related thematic reading for financial-crime context sits in the sanctions and AML trade finance hub, with desk primers in the export finance and project finance hubs.
Summary for credit and compliance stakeholders
Data residency and compliance on Stonewake is a public commitment set: EU and UK hosting for the database and backend, a separate US-based edge-delivery layer for the website and dashboard front end, no Stonewake model training on customer data, organisation and country emphasis on core screening surfaces, human confirmation of drafts, an append-only audit ledger, and AI transparency notices under Article 50. Institutional obligations under GDPR, national AML rules, and a bank's own policies remain with the bank. Stonewake supplies cited intelligence tooling inside those constraints.
Roles: controller and processor
Stonewake's public privacy documentation separates processing into distinct lanes. Website and outreach processing follows Stonewake's own privacy notices, with Stonewake as controller under Article 6(1)(f) GDPR for that processing. Bank-instructed research and screening, where the bank determines the purpose, runs as processor work: Stonewake processes on the bank's documented instruction under a data processing agreement concluded per Article 28 GDPR with each customer bank. This methodology page does not reproduce the full privacy policy; it flags that role separation as part of the compliance design reflected in that document.
Published retention figures attach specific horizons to each lane: audit ledger records persist for the duration of the customer relationship plus statutory retention; bank-instructed screenings carry a retention horizon set per screening by the bank, enforced by a daily purge job, and are erasable on demand; server logs are kept for at most three days. Erasure and purge behaviour described in the public privacy policy is part of the documented design rather than a claim exclusive to marketing copy.
Practical checklist for credit and privacy stakeholders
Data residency and compliance review typically covers:
- where the primary database and backend regions sit (European Union and United Kingdom) relative to a bank's outsourcing policy, and that the website and dashboard front end route through a separate US-based edge-delivery layer
- that Stonewake never trains models on customer data
- that draft scores and verdicts require human confirmation
- that screening and Deal Book outputs are decision-support artefacts, not sole automated decisions about persons
- that sanctions and PEP list controls remain on the bank's own systems of record
The sanctions and AML trade finance, export finance, and project finance hubs give institutional vocabulary for those discussions without exposing product internals.
Alignment with desk operating models
Data residency and compliance commitments connect to how EF, PF, and CRE teams work day to day. Origination workflows depend on Deal Book exports and screening packs entering credit files without creating an uncontrolled personal-data side channel. The compliance framing depends on Stonewake's drafts not silently becoming automated decisions. The controller and processor roles set out above give privacy counsel a documented starting point ahead of go-live.
The public methodology emphasises human confirmation, organisation and country emphasis on core screening surfaces, and a stated rule that Stonewake never trains models on customer data. A pilot commonly exercises the same lifecycle described above: starting a screening, confirming a verdict, exporting a workbook, requesting erasure where applicable, and checking audit visibility, since those behaviours sit in the product and its documented policies rather than in marketing claims alone.
Monitoring feeds and public country pages are lower-sensitivity surfaces than authenticated Deal Book timelines. Even so, the same citation discipline and labelling practice described in citations and evidence apply across both.