Linking data across organizations without exposing it

The challenge

Organizations in the sector each hold personal data that has to stay inside their own walls: transaction references, record keys and personal identifiers. Linking those datasets has real value, and under GDPR, pseudonymized exchange is the legal route to doing it. What was missing was a way to produce matching pseudonyms across organizations, so records could be joined without anyone revealing the original values.

That made it a three-way trust problem. The operator had to apply a secret key to data it could not read, and keep nothing afterwards. Each customer had to receive pseudonyms without ever learning the key. Two customers had to get identical pseudonyms for identical inputs without ever connecting to each other.

The constraints were strict. Customer environments have no public internet access, so everything had to run from an on-premises VM that only opens outbound connections. Confidentiality obligations mean documents and identifiers cannot leave the customer's premises in clear. Files had to be processed whole and in place, with the same structure and column order and only the selected columns replaced. Every exchange needed a long-term audit trail. And for the client, the commercial stakes were simple: without a working platform, there was no product to price.

Our solution

The engagement opened with a design sprint, not a build. Sprint 0 covered SSH tunnelling feasibility, a streaming transport proof of concept, a cloud capability assessment, research into local file access, UI/UX design for both applications, and the monorepo and API foundations. A five-person Reshape team spanning design, frontend, backend, infrastructure and product management ran delivery from day one, with regular sprint reviews alongside the client.

That investigation turned the architecture described in the contract into something simpler and stronger.

Outbound-only SSH tunnels in place of the contracted VPN

The statement of work assumed a VPN with certificate management. Reshape proposed SSH tunnelling through a bastion instead: outbound only from the customer, host-key pinning, key-based authentication, and a fail-closed default if the tunnel drops. The client service and the processing job meet at the bastion, so the processing job keeps a private IP and is never reachable directly. The admin API handles control only and sits outside the data path. Customer keys are authorized against the platform database at the moment of connection, so onboarding a new organization never touches a static configuration file.

Ephemeral compute, so nothing persists on the operator side

Rather than provisioning containers, queues and storage per project, each processing session runs as a short-lived serverless job that is destroyed on completion. Cost scales with usage, and nothing is left behind to secure. Together with the client, the team went a step further: pseudonymized output is written straight back to the customer's own SFTP server, next to the input, and every download path was removed from both applications. The platform never holds a readable copy of customer data.

Verifiable pseudonymization that two organizations can join on

The cryptographic core is an externally provided verifiable OPRF library, supplied by the client. Reshape integrated it into production and built the full pipeline around it. Each selected value is blinded on the customer side with a single-use mask. The processing job applies the work-package key and returns a zero-knowledge proof, and the customer side verifies and unblinds the result into a fixed 64-byte pseudonym. A wrong or dishonest key evaluation is caught before it can silently produce inconsistent pseudonyms.

Because the output is deterministic under the same key, two organizations in one work package receive identical pseudonyms for identical identifiers and can join their datasets. Only blinded values ever leave the customer's environment. Columns that are not selected never leave at all.

Whole-file processing, streamed end to end

CSV, XLSX and archive files are processed as streams and never loaded whole. Selected columns are blinded mid-stream in batches, archives are handled entry by entry, and the output keeps the original structure and column order. An archive goes in, an archive comes out.

Two applications, one operating model

The admin application gives the operator passwordless login, customer onboarding, API key management, work package management, per-file operations monitoring and an append-only audit trail of every change. The customer application runs on the customer's VM as a desktop app backed by a local service. Users browse their own SFTP folders, choose files and the columns to pseudonymize, submit, and follow progress through work-package KPIs. Both applications are multilingual, and the Windows installer is built in CI.

Secure sharing between organizations

Cross-customer sharing adds one layer on top of the full pseudonymization pipeline rather than replacing it. The pseudonymized file is encrypted once with its own AES-256-GCM key and uploaded once, whatever the number of recipients. That key is then wrapped separately for each recipient with RSA-4096. Recipients decrypt on their own VM and deliver the file to their own SFTP. The platform relays ciphertext only, and retention is enforced by deleting the wrapped keys. Sharing is code complete and in client acceptance testing.

Performance and scale

The platform is multi-tenant by design: many customer organizations, many work packages, and one dedicated key per work package, held in a managed secret store and referenced by ID only. Processing is streamed end to end, with values blinded in batches and several batches in flight at once, so file size is not bounded by memory. Shared files move in encrypted chunks through parallel multipart uploads.

Compute for processing is ephemeral, which means no fixed worker pool and no persistent infrastructure to size in advance. Scheduled jobs handle the housekeeping: share retention, tunnel session cleanup, stalled operation sweeps and the key lifecycle, which keeps each work-package key active for a year and archived for six months before it is purged. Two isolated development environments let the team test two "customers" against each other before anything reaches production.

Tech stack

The backend runs on .NET 10 with ASP.NET Core minimal APIs, Entity Framework Core and PostgreSQL, with Audit.NET providing the JSONB audit log and signed, encrypted JWTs for authentication. The on-premises customer service is also .NET 10, using SignalR, gRPC and SSH.NET for tunnels and SFTP, CsvHelper and MiniExcel for streaming file processing, and the platform's built-in AES-256-GCM, RSA-4096 and Windows DPAPI for encryption and key storage. The externally provided OPRF library, written in Rust on Ristretto255, is integrated through a C ABI and .NET P/Invoke. The frontend is built in Angular 21 with PrimeNG and AG Grid, wrapped in an Electron desktop shell. Infrastructure runs on EU-hosted cloud services, across serverless containers, serverless jobs, object storage, secret management and a hardened bastion VM, with CI/CD on Bitbucket Pipelines. The codebase is covered by more than 330 automated tests across the admin API, customer service and frontend, plus Rust unit tests and benchmarks.

Impact and results

• From contract to working pseudonymization in under three months. The investigation sprint closed within weeks of signing, and the first end-to-end pseudonymized files followed less than three months after the contract. Architecture documentation, user guides and a data model reference followed.
• Client-verified conformance. The client's own review of the statement of work found the admin application, customer application, encryption layer and infrastructure to be in conformance, including the SSH tunnelling and ephemeral compute that replaced the original design.
• Zero readable copy on the operator side, by architecture. Only blinded values cross the boundary during processing, output goes straight to the customer's own SFTP, and shared files exist operator-side only as ciphertext and wrapped keys. This gives the client a defensible basis for its GDPR position and its data protection impact assessment, now in progress.
• Cross-organization joins without exposure. Two organizations can now link records on identical pseudonyms without either one seeing the other's data or the key. This was demonstrated by joining two independently held datasets on a shared identifier.
• A product the client can take to market. A further prospect has already asked for an anonymization module, and the client has requested infrastructure costing to price platform usage.

What's next

The engagement is active. Cross-customer sharing is moving through acceptance testing and into production. Alongside it, the team is completing the work package lifecycle, including automatic and manual close and infrastructure deprovisioning, adding support for locale-specific file formats such as semicolon-delimited CSV, and revising the user guides based on customer feedback. A system-wide KPI dashboard is ready to follow once the client confirms which metrics matter most.

Two new workstreams are under discussion. The first is an anonymization mode: the same pipeline, with the key destroyed immediately after use for irreversibility, verified against established re-identification criteria and backed by a signed certificate from the platform. The second is AI-assisted anonymization of unstructured documents, running on premises only, with mandatory human validation and no external model calls. Both build on the trust model already in place.