API documentation

Data handling

What Stonewake ingests, stores, and serves, on one page. The research base is registers, courts, regulators, tenders, filings and the trade press; your workspace data stays yours.

Sources and citations

  • The research base is public data only. It covers official company registers and gazettes, court and insolvency publications, regulatory filings, the LEI system, public procurement records, official statistics, licensed reference datasets, and reputable press.
  • Findings carry citations to their public origin, down to the quoted passage, so every claim can be checked at its source.
  • Scores apply to organizations and countries, never to natural persons. A sole trader's business counts as a natural person, by the registers' own evidence (a German legal form of a natural person, the e.K. or e.U. designation of the firm name, or a sole proprietor's legal form or category in the GLEIF record). Where these sources disagree, the German register extract decides when there is one; without it, any of them stating a natural person's business decides, and the disagreement is recorded for review. It carries no score, status, status change, risk alert, news tone or social sentiment, and no such value of one is kept, while its register facts, insolvency notices, news articles, news events and social posts are read like a company's. A person your workspace watches carries the tone of its news and posts as context for your institution, never as a score of the person.
  • Where person data is switched on for a workspace, the natural persons that official registers and the official sanctions lists name (officers, shareholders, beneficial owners and listed persons) are served to that workspace with their citations, in the dashboard, the API and MCP alike, for know your customer, sanctions and credit due diligence on organisations and their people. The sandbox and our public pages serve none. A person who objects is no longer shown as a register or list person on any of these surfaces, and a person who leaves a sanctions list is deleted from our copy of it in the same update. Adverse media screenings of natural persons, which your analysts request in the dashboard, and research runs about a natural person are read through the API and MCP under the same switch, as findings with their sources and never with a verdict or a score. Such a screening holds a name and no register entry, so an objection is answered by erasing it, together with any dossier on the person. A natural person your workspace watches is followed in news and social monitoring and alerts like a company, and a person can be a research target with the purpose your analyst records, whose runs are erased with the target. None of them is ever scored. The public records notice names the sources and the recipients. Every API and MCP response that serves a natural person writes one access record naming the workspace, the API key, the route and the ids of the persons, records, screenings or runs it served, never a name. This covers a risk row that names a listed person.

Retention

  • Workspace data is retained while your arrangement is active. Bank-instructed screenings are stamped at creation with the retention horizon agreed with your bank, enforced by a daily purge; absent an agreed horizon they are kept until erased, and every screening and every dossier on a person is erasable on demand.
  • Database backups are encrypted, held apart from the production server, and kept for a defined retention window; restore procedures have been exercised.
  • On offboarding you export your reports and data during a wind-down period; workspace data is then deleted, and the entries of the audit ledger are retained after the arrangement ends. They hold identifiers, among them the email address of a member an administrator invited or removed or who first signed in through single sign on, and no screening content, except feedback reports, which keep their text and the reporter's email address until a scrub removes both from entries older than 180 days. The API security page carries the same posture for the programmatic surface.
  • The GDPR basis for each processing purpose is set out in the privacy policy; public-register facts follow the public records notice.
  • 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. Search queries, fetched public text and the text sent to AI providers for drafting, including the subject of a screening, are processed by search and AI providers as described in the privacy policy, sections 7 and 8. For a workspace that its contract places on the EU route, every language model call goes to Claude in Amazon Bedrock in the AWS region eu-north-1 in Stockholm, Sweden, and a call that region cannot serve fails instead of going to another provider. A workspace can be limited by arrangement to a named set of these search providers and to a text embedding model of its own. The full processor list and the Article 32 measures are part of the data processing agreement provided to customer banks.
  • Sources your bank brings, the alerts of its own tender portal accounts and the values of a company data provider it licenses, are processed for your bank only and stay in its workspace. Such a provider is called under your bank's own key, on your bank's instruction, and the key is stored encrypted for your bank only. See Your own sources.
  • We store your workspace records on our infrastructure and do not train models on them.
  • The audit trail records, for each research run, screening, screening summary, deal briefing run, report and pack that called a language model, the provider and model that answered each of its calls, a fallback provider included, and the model that was planned where it differs. A record that cannot show which model answered says so and never names the planned model instead. On the AI controls page an administrator sees these calls counted per provider and model for the last 30 days.

See also Security overview, Terms of use.