Secure Multi-Party Computation: Roseman Labs vs mintBlue
Secure multi-party computation (Roseman Labs) computes in the blind. mintBlue streams blinded, provable data so MPC can scale. Where each fits.
Niels van den Bergh
CEO
September 28, 2026

Introduction
Banks, supervisors, ministries and companies in a supply chain keep running into the same wall. The insight they need is spread across several organisations, and none of them can or should hold everyone else's raw data. Secure multi-party computation is one of the best answers the privacy field has produced for that problem, and in the Netherlands one of the best-known names in it is Roseman Labs. mintBlue comes up in the same conversations, and we regularly get asked: isn't that just MPC?
The honest answer is that the question compares two different kinds of thing. Secure multi-party computation is a cryptographic technique. mintBlue is privacy-preserving infrastructure: a runtime for data sharing between organisations, built from standard, well-studied cryptography such as encryption, key agreement, signatures, hash commitments, key derivation, delegation and oblivious pseudorandom functions, a primitive that also sits underneath many MPC protocols. The two also reinforce each other. Because data moves through mintBlue as a stream of blinded events, an MPC computation can work on what is new instead of on complete data sets, which addresses one of the biggest practical limits of MPC. So the useful comparison is functional: which problems of privacy-preserving data sharing does each one solve, how, and where do they meet.
What secure multi-party computation actually does
Secure multi-party computation (MPC) lets several parties compute a joint result over their combined data while, under the protocol's security assumptions (typically that the compute servers do not collude), no party and no single server sees anyone else's input.
The most common approach is secret sharing. Each party splits every value into random-looking pieces, called shares, and sends them to independent compute servers. A single share tells you nothing. The servers run the calculation on the shares, exchange intermediate values according to a cryptographic protocol, and at the end they reveal only the output everyone agreed to reveal.
The classic example: five colleagues want to know their average salary without anyone disclosing their own. With MPC they get the average and nothing else. Nobody learns an individual number, including whoever runs the servers. MPC protects the inputs during the computation. What the output itself reveals still has to be designed and governed, which is why approval of queries matters.
In practice MPC is used for three kinds of work:
- joint statistics across organisations, for example outcomes across several hospitals
- finding overlap between datasets, often through private set intersection, which tells two parties which records they have in common without exposing the rest
- training or scoring models on data that cannot be pooled
What you get back is an answer: a number, a table, a match list, a model score. That is the point of the technology.
How Roseman Labs puts MPC to work
Roseman Labs builds an encrypted computing platform for analysis on data from multiple participants. Their own summary is "encrypt, link & analyze sensitive data". Data is split into encrypted shares and distributed across independent servers, where, in their words, a single server "sees only random numbers". The raw data is never reconstructed, and only the outputs a participant has permitted are revealed. The platform can run in the cloud or fully on-premise.
Analysts work with it through Crandas, a DataFrame library for the Roseman Labs cryptographic engine. It supports the things analysts expect, such as filters, joins, group-bys, aggregations and common machine learning models. Governance is built in. An analyst first designs a script on dummy data, a fixed set of approvers signs it with their approver keys, and only then can it run on real data. Roseman Labs also states that every action on the platform is logged and verifiable.
The company works in healthcare, government and anti-financial crime, including the Central Bank of Ireland sandbox, where, the company says, it demonstrates how its platform aligns with Article 75 of the new EU anti-money laundering regulation. Its technology is behind the 2026 Dutch Privacy Award, which the Privacy First Foundation gave to UMC Utrecht, and in our view deservedly so.
What mintBlue is: infrastructure built from standard cryptography
mintBlue combines several privacy techniques, each chosen for one job. It is a runtime in which each organisation keeps its own data and its own keys, and in which every exchange between organisations is an encrypted, signed and anchored event that each participant can replay and verify for the events it is entitled to see.
Authority is part of the record. A mandate, meaning the right to act on someone's behalf, is a scoped, time-bound, revocable delegation that our runtime checks at every action. So the log shows not only that a municipality sent a file to a ministry, but that the person who sent it was allowed to, at that moment, for that purpose.
The easiest way to picture the whole: MPC is a calculator that nobody can look inside. mintBlue is closer to a postal system where everyone seals their own envelope, the carrier delivers it without opening it, and every handover is stamped into a tamper-evident logbook with verified authority behind each stamp.
| Building block | What it does in mintBlue |
|---|---|
| Encryption with key agreement per recipient | Share only what a counterparty needs, down to the field: each recipient can open only what was encrypted for it |
| Signatures over the encrypted content | Prove who created a record, and when, without revealing what is in it |
| Hash commitments, anchored in a tamper-evident log | Prove that a record existed, unchanged, at a given moment |
| Elliptic-curve key derivation (point addition, per message) | A unique key for every exchange, derived independently by both sides, so a leaked message key exposes only that message |
| Scoped, time-bound, revocable delegation | Record and check on every action who may act on whose behalf |
| Oblivious pseudorandom functions (OPRF) | Blind an identifier at the source into a token that matches across organisations; the token is computed by a separate key holder that never sees the identifier |
| Append-only event streams | Every organisation publishes its changes as they happen, so a counterparty or a computation only has to process what is new |
The same problems, two toolkits
| Problem | Roseman Labs (secure multi-party computation) | mintBlue |
|---|---|---|
| A joint statistic, aggregate or model over data nobody may see | The core strength: computation on secret shares, only the approved output is revealed | Feeds the computation: blinded, signed inputs streamed from each source, so the MPC run only has to process what changed, and each result is recorded with the authority behind it |
| Finding overlap between lists without revealing them | Private set intersection inside the MPC platform | OPRF tokens computed at the source and streamed as they occur, with a match signal only when enough parties hold the same token |
| Handing specific information to a specific party | Outside its purpose: it reveals results, never the underlying records | Per-field encryption and key agreement: the recipient opens only what it needs |
| Proving who shared what, when and under which mandate | Every action on the platform is logged and verifiable (per Roseman Labs), scoped to the computations run there | Signed, anchored events, verifiable by each participant, with delegation checked at every action |
| Erasure on top of an immutable record | Not applicable: inputs are never stored in the clear | Personal fields sit off the log and can be deleted, while the anchored record keeps only a commitment |
| Time horizon | A defined analysis, run when approved | Continuous: an ongoing record of exchanges |
Making MPC scale: blinded streams and append-only computation
MPC has a known cost problem. Every value is split into shares, and every operation on those shares means communication between the compute servers, so the work grows with the size of the data sets involved. For a one-off analysis that is acceptable. For a question that has to stay current, such as whether a customer who showed up at one bank today already appears at two others, recomputing an intersection over every party's full customer base each time something changes quickly becomes the bottleneck.
The way data moves in mintBlue changes that equation. Each organisation publishes events as they happen, into an append-only stream. Identifiers are blinded at the source with an oblivious pseudorandom function before they enter the stream, so what travels is a token that matches across organisations and says nothing about the person behind it. Earlier events and earlier results are anchored in the log and do not change.
That lets the MPC layer move from batch to incremental work. Instead of running over complete data sets, it computes over the latest values only: the tokens and fields that arrived since the previous run, combined with state that is already settled. The expensive cryptography is spent on what changed, and the rest is carried forward from a record every party can verify.
In practice this means:
- matching runs on blinded tokens, which are cheap to compare, so the heavy MPC protocol is reserved for the steps that need it
- each run touches only the events since the last one, which ties its cost to the rate of change rather than to the size of the history
- inputs arrive signed and anchored, so the computation knows where every value came from and under which mandate it was shared
- every result is recorded as an event of its own, which gives the next run its starting point and the supervisor its audit trail
A real test: Article 75 AMLR partnerships
From 10 July 2027, Article 75 of the EU Anti-Money Laundering Regulation lets banks and other obliged entities form information-sharing partnerships to detect money laundering and terrorist financing together. It comes with strict safeguards: supervisors must verify the partnership before it starts (Article 75(2)), a data protection impact assessment is mandatory, and the partnership has to keep full records and can be audited.
How to build such a partnership without turning it into a surveillance machine is the subject of a European positioning paper we contributed to: "Exclusion by Design: A Privacy-Preserving Architecture for Financial Intelligence Sharing Partnerships in the EU". It argues that privacy enhancing technologies are non-negotiable for Article 75 partnerships, and that supervisors should judge them on four outcomes rather than on a named technique:
- no party can access another party's plaintext customer data
- re-identification by the analytical platform is technically infeasible
- purpose limitation is enforced by the architecture, not by procedure alone
- the risk of indirect re-identification is actively minimised
On the central technical question, finding the same person across several banks without anyone seeing identifiers, the paper argues that MPC with private set intersection is the recommended approach, because it keeps data encrypted during computation and hard-wires purpose binding into the protocol. We agree that this is the right tool for that step. The paper also says other approaches can pass if properly implemented, including what it calls "federated analysis with cryptographic audit trails", and it warns supervisors against locking themselves into a single technique. The paper does not endorse any vendor, us included. For that step mintBlue works with MPC: it supplies the blinded, streamed input that keeps the computation incremental as new transactions and new customers come in.
That is our reading, not the paper's. If you have to run a partnership rather than just design one, you see two layers.
The computation layer is entity discovery and network analysis in the blind. That is where MPC is strong, and where Roseman Labs has put its platform. Fed by blinded streams from each bank, it can keep that analysis current by processing each day's new reports rather than re-running over every bank's full history.
The exchange and accountability layer is everything around it. The scope and exclusion decisions a supervisor has to verify before launch. Re-verification every time that scope changes. Records of who accessed what, under which mandate. Alerts that go back to the banks carrying a partnership identifier, so the financial intelligence unit can recognise that several suspicious transaction reports belong to one pattern. That layer is about exchange, identity and proof over time, and it is the one mintBlue is built for.
When to use which
Choose secure multi-party computation when your problem is a bounded analytical question across a known set of parties. You need a shared statistic, an overlap, a match or a model, and you need the answer rather than a running record of who sent what to whom.
Choose mintBlue when data and decisions move between organisations over time, when the other party is a supervisor, a regulator or a counterparty who will want proof later, and when the question "was this person allowed to do this, at that moment?" has to have a verifiable answer.
Choose both when the analysis has to stay current inside a regulated exchange. In an Article 75 setting, mintBlue streams blinded identifiers from each bank, MPC finds the shared entity on what is new, and mintBlue carries the resulting alert, the mandate behind each step and the trail the supervisor checks.
How the two combine
In one direction, mintBlue feeds MPC: blinded tokens and signed, provenance-checked events, streamed from each source, so the computation runs on the latest values instead of on complete data sets. In the other, the output of each MPC run flows back into mintBlue as an event, so it is clear afterwards which analysis ran, on whose authority, and what came out, and the next run starts from there.
If your need is to compute a shared answer in the blind, MPC is built for that and Roseman Labs is a strong option. If that answer has to stay current as data keeps arriving, and every exchange around it has to be provable, mintBlue is the infrastructure underneath.
FAQ
Is secure multi-party computation a privacy enhancing technology?
Yes. Privacy enhancing technologies (PETs) are techniques that let you use data while limiting what is exposed. MPC is one of them. Others include homomorphic encryption, confidential computing with secure enclaves, pseudonymisation and differential privacy. Each protects data in a different way, and many real systems combine several.
What are the limits of MPC?
MPC is at its best for computations that are defined in advance and run on request. It is computationally heavier than calculating in plaintext, and its cost grows with the size of the inputs, so re-running an analysis over complete data sets every time something changes gets expensive. Streaming blinded inputs and computing only over what is new keeps that in check. By design MPC returns answers, not records: it does not by itself give you an ongoing account of what was exchanged between organisations over time.
Is this the same MPC that crypto wallets use?
Same idea, different job. Wallet providers use MPC to split a signing key so no single device or person holds all of it. Platforms like Roseman Labs use MPC to run analytics on data from several organisations. The cryptography is related, the use case is not.
Does mintBlue use secure multi-party computation?
mintBlue shares building blocks with MPC protocols. Oblivious pseudorandom functions, for example, underlie many private set intersection protocols, and our token matching for fraud-fighting authorities is built on them. Where a partnership needs a full joint computation over hidden inputs, mintBlue works alongside an MPC engine: it streams blinded, signed inputs so the computation stays incremental, and it records every result.
Is Roseman Labs a competitor of mintBlue?
Not really. Both come up in the same conversations about privacy enhancing technologies, but they cover different layers: Roseman Labs computes on data nobody can see, mintBlue carries and proves the exchange of data between organisations. Put together, mintBlue can make an MPC deployment cheaper to keep current and easier to audit.
If you are designing an Article 75 partnership or any other data flow between organisations and are wondering which layer you actually need, talk to us. For the adjacent comparison with clean rooms, read Beyond Data Clean Rooms.