Twelve European banks, six questions.

The setting

Between May and August 2025 we briefed twelve banks on the Estøkad architecture. Eight of them were universal banks with retail, commercial, and asset-management arms. Two were private banks. Two were payments-focused institutions. The smallest had €4 billion in assets under management; the largest had €420 billion. Every meeting had at least one person from compliance and one from platform engineering present. Most had procurement on the call as well.

The reason a private-equity-funded headless CMS is in the room with a tier-one bank in 2025 is straightforward: the existing CMS contract is up for renewal, the platform team has a list of grievances, and the compliance team wants the DORA Article 30 clauses tightened. We were the European-domiciled option on the shortlist.

Question one — "where exactly is the data"

Every CIO asked it. The right answer was a screenshot of the residency-proof attestation and the underlying signed JWT. Verbal assurance does not survive an internal-audit challenge. Customers wanted to see that their auditor could fetch a cryptographic attestation directly from the workspace JWKS without our involvement.

The follow-up was always the same: "and during a failover." The answer is that Estøkad does not do automatic cross-region failover. Customers paying for the EU failover backup module get nightly encrypted copies to a designated secondary EU country, the secondary stays cold, and promotion is a contractual customer action. The trade-off surprised nobody once it was on the table; the "data was here" answer for the supervisor mattered more to them than the seconds-to-recovery number.

Question two — "what is the exit plan"

Three of the twelve had been burned by a previous vendor exit that ran past 90 days. Two had been burned by a vendor that exported content as HTML rather than as structured data, forcing a rebuild project they had not budgeted for.

Our exit plan exports schemas as TypeScript that compile against @estokad/schema; content as JSON in a stable, publicly documented IR; assets as a tar archive with original filenames and metadata; the audit log as JSONL with the Merkle roots required to re-verify off-platform. The 90-day window is contractual and the export is automated. Nobody pushed back on the design once they saw it; they pushed back on whether we would still exist in five years to honour it.

Question three — "who gets root on production"

The honest answer is: a small number of named on-call engineers who are EU residents, identified in the sub-processor register, with each session logged into the audit chain and each elevation requiring a second approver. Customers wanted to see the names — not publicly, but in a vetted document for procurement. We agreed to add named operator attestations to the trust centre for paying enterprise customers.

The compliance teams cared less about the technical mechanism than about the structural guarantee that no US-domiciled person could be compelled, under any standard legal process, to access the data. The Estonian entity, the EU-resident operations team, and the EU-only sub-processor list together gave them an answer they could put in their own board paper.

Question four — "how do you handle a critical incident"

Article 19 of DORA defines the reporting timelines for major ICT-related incidents. The financial entity must report within four hours of classification; an intermediate report within 72 hours; a final report within one month. The vendor needs to support that timeline operationally — meaning a customer cannot be told to file a support ticket and wait.

The roadmap commitment that landed in the briefings was the runbook: a customer-facing incident page that updates within minutes, a webhook that fires the moment the incident is classified by us, and the audit-chain record that the customer can attach to their own filing without redaction. We are shipping this in Q4 2025.

Question five — "what if you get acquired"

Asked in eleven of the twelve meetings. The structural answer is the trademark, the jurisdiction, and the exit plan. The trademark is held by the Estonian parent; an acquirer takes the company subject to the existing customer commitments. The jurisdiction is hard to move — the Estonian entity is the contracting party, and the courts that hear customer disputes are Estonian. The exit plan is enforceable independently of who owns the company; if the new ownership changed the residency posture, every customer in the affected region could trigger their exit clause.

Two compliance teams asked for a written acquisition notification clause — 90 days' notice, customer right to terminate without penalty if the acquirer is non-EU. We added it to the standard MSA in August.

Question six — "what does it cost"

The pricing page surprised everybody. Public EUR pricing without a contact-sales wall is unusual at the regulated-buyer end of the market. The Enterprise preset undercuts the incumbent we were displacing in eight of the twelve cases by 30 to 45 percent on comparable scope. The remaining four were greenfield builds where the incumbent was not in the picture; in those, the question was whether the bundle covered everything they needed, and the answer was usually yes.

What changed on our end

The named-operator attestation, the acquisition notification clause, and the customer incident webhook all came directly from these briefings. The roadmap entry for the per-region status page also came from these conversations — banks wanted to see incident history per region, not aggregated.

Pricing at /pricing, roadmap at /roadmap, the trust posture at /trust. The right next step is usually a conversation — /contact.