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 a dedicated server in Helsinki for the database, the API, the audit trail and the MCP server, 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 where the service runs. The database, the API, the audit trail and the MCP server run on a dedicated server of a German provider in Helsinki, Finland. The web pages of the dashboard, the documentation and the website are delivered by Vercel, a US company, over its global delivery network, which also runs the request routing step of the website. All other server functions of the three run in its Frankfurt region. Sign-in runs through a managed service in London. The delivery network can answer a request from any of its regions, so technical request data can be processed outside the European Union. Search and AI providers process search queries, fetched public text and the text sent to them for drafting, including the subject of a screening, under the terms in the privacy policy, sections 7 and 8. 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 processing personal data in the EEA and, via the UK regime, informs UK expectations under the adequacy arrangement described above. Stonewake's public compliance language describes a published notice under Article 14 GDPR for data from public registers, no score, rating or ranking of any person, 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 a replacement for 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, 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.

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 customers or 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. It covers a dedicated server in Helsinki for the database, the API, the audit trail and the MCP server, web pages delivered over a global delivery network with all other server functions in Frankfurt, sign-in through a managed service in London, no Stonewake model training on customer data, 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 of 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 rules state a rule for each lane: audit ledger records persist for the duration of the customer relationship plus statutory retention; bank-instructed screenings are erasable on demand at any time, and where a retention horizon is agreed with the bank, an automated purge enforces it; website 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 dedicated server (Helsinki), the sign-in service (London) and the server functions of the web layer (Frankfurt) sit relative to a bank's outsourcing policy, and that the web pages are delivered over a global delivery network
• 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 and a stated rule that Stonewake never trains models on customer data. An evaluation 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.