Secure Multi-Party Computation for Shared Network Intelligence Across Firms

Two funds sit across the table at a co-investor dinner, each aware that the other probably knows someone useful: a portfolio company's next hire, an LP considering a new commitment, a founder weighing a term sheet. Neither will hand over a contact list to find out. That hesitation is the entire problem this piece addresses, and it is the reason cross-firm relationship intelligence has stayed largely theoretical despite the obvious value on the table. Co-investors, LP-GP pairs, BD partners, and deal syndicate members are exactly the people most likely to benefit from discovering a shared warm path to a target, and they are simultaneously the people with the strongest institutional reasons never to expose their contact graphs to one another.

Relationship data carries more weight than a simple address book. A firm's network encodes its sourcing pipeline, its LP relationships, the introductions it has made into portfolio companies, and the shape of its deal flow. Showing a counterparty who a firm knows is close to showing that counterparty how it wins deals. For a fund competing against another fund for the same allocation or the same acquisition target, that is not a disclosure made lightly, no matter how much goodwill exists between the two parties on a given Tuesday.

Firms have tried to route around this by appointing a trusted third party to hold the combined graph, but that third party simply becomes a new single point of failure that every participant must trust instead. Whoever holds the pooled data becomes a single point of failure for every participant at once. Siloed graphs, redundant outreach to the same targets, and warm paths that would have existed had either party been able to see the other's edges persist across the market because neither party was willing to go first.

Private set intersection as the right primitive for network overlap

Secure multiparty computation gives firms a way to go first without actually going first. NIST's Privacy-Enhancing Cryptography project defines Secure Multiparty Computation as a class of protocols that let multiple parties jointly perform a computation using everyone's inputs, without those parties ever sharing their private inputs with one another, and depending on the function being computed, each party can also walk away with its own private output. The computation itself happens in a kind of blinded state: participants never see the raw values feeding the calculation, only the authorized output they are entitled to see at the end.

That property separates SMPC from the encryption most firms already rely on. One European data protection regulator describes SMPC differently: confidentiality holds throughout the computation itself, not just before and after it. Call it computing without exposure. Nobody's underlying data is ever decrypted to produce the answer.

Within that broader class of protocols sits Private Set Intersection, the specific tool suited to a network-overlap question. Applied to relationship data, PSI answers "who do we both know?" directly: two firms run the protocol, and each receives only the names of shared connections. Neither firm learns who the other knows exclusively. Neither firm learns the size or shape of the other's full contact graph. What crosses the boundary between them is the intersection, the one piece of information both parties actually wanted.

From "who do we both know?" to warm path discovery

Finding out that two firms share a connection to the same person answers only the first question. The second, more useful question is whose relationship with that shared contact is strong enough to carry an introduction, and that question is where the real value of the system lies. A fund trying to reach a target company's CEO can run a PSI query against a co-investor's graph and learn that both firms share contact X. Scoring that relationship, deciding how warm the path actually is, is a separate computation entirely, and it is one each firm runs privately on its own side of the connection.

This is what makes the architecture coherent rather than just clever: PSI handles the question of set membership, meaning who is shared between the two graphs, while each firm's internal relationship intelligence layer handles the separate question of path quality, meaning how strong that firm's own edge to the shared contact is. These two computations do not depend on each other and do not require each other's inputs to be exposed. A firm can score its own relationship to contact X using whatever signal it already has, email cadence, meeting frequency, mutual introductions, without ever showing that scoring data to the counterparty, and the counterparty can do the same on its side.

What reaches the end user is a ranked list of warm introduction paths to a target. That distinction matters operationally as much as it matters cryptographically. A professional looking at that ranked list can decide whether an introduction is worth asking for and can draft the outreach accordingly, but the decision to make the ask, and the judgment about whether the relationship can bear the weight of it, stays with the person. The system surfaces the path. It does not act on it. Relationship data that was never fully exposed to the counterparty in the first place is not the kind of thing a system should be making autonomous decisions about, and the layered design keeps a human in that seat by construction, not as an afterthought.

The firms that benefit most from cross-firm network intelligence are also the most exposed to its risks

The firms with the most to gain from seeing across the boundary of their own network are, almost without exception, the firms with the most reason to guard that boundary. That is not a coincidence. That follows from how competitive advantage is built in relationship-driven industries, and the exposure looks different depending on which seat a person sits in.

Consider investors first. A relationship intelligence system can surface warm paths across a firm's entire network, including paths that run through a partner who left the firm two years ago. There is rarely a permissioned mechanism for retaining what that departed partner knew. The firm's effective network shrinks the moment a senior person leaves, regardless of what the org chart says.

Platform teams at funds face a related but distinct version of the problem. Once a fund invests in a company, that portfolio company needs introductions constantly: to customers, to hires, to channel partners, to follow-on investors for the next round. A siloed network means those introductions get routed through whichever team member happens to personally know the right person, rather than systematically through the full firm's accumulated relationships. That is a structural disadvantage, and it compounds across every portfolio company a fund holds at the same time, because the same bottleneck repeats at each one.

BD operators carry a third version of the same exposure. The highest-value warm path to a target OEM or a distribution partner may already exist somewhere inside the firm's network. It is often invisible to the person who needs it because the relationship data documenting it is scattered across inboxes, calendars, and messaging threads that nobody has ever mapped into a single view.

What ties all three cases together is a return on capital, not a convenience. A firm competing on relationships competes on conviction. The network advantage appears directly in the numbers a fund reports to its LPs. That is precisely why the same firms most eager for cross-firm intelligence are also the firms least willing to accept anything less than a cryptographic guarantee that their side of the ledger stays closed. A governance agreement might satisfy a friendly counterparty. It will not satisfy a rival fund competing for the same deal, and MPC is the only architecture built to make that distinction irrelevant.

Computational cost

None of this is free, and the honest version of this argument has to say so. SMPC carries real computational overhead, and that overhead is the thing that currently determines which queries are practical today and which remain aspirational for another product cycle. One European data protection regulator, reflecting on a recent privacy engineering workshop, names the constraint directly: the technology is computationally intensive, the extra communication and processing required slows performance in any use case that demands real-time responsiveness, and scaling the approach to large multi-party scenarios remains a significant technical challenge.

For relationship intelligence, that constraint lands precisely on the query type that sounds most impressive in a demo: "find the strongest introduction route from our firm to this CEO, right now." A query that takes hours instead of seconds does not fit into how deal sourcing or BD outreach actually works day to day. Nobody is going to pause a live conversation with a target to wait on a slow cryptographic handshake between two firms' systems.

A second constraint sits next to the first one. An engineering cost appears before a firm ever runs its first query, in the work of wiring the protocol into systems that were not built with it in mind.

Where the objection actually loses force is in how most institutional relationship queries get used. The constraint bites hardest on large contact graphs queried in real time, and it bites much less on batch operations: nightly intersection runs, pre-computed overlap maps, periodic reconciliation between two firms' networks. Most relationship intelligence actually gets consumed as groundwork done before a sourcing process starts, not as a live lookup mid-conversation. Discovering a warm path exists at the outset of that process, even from a batch run completed overnight, delivers most of the value a real-time system would, without demanding the latency a real-time system would need.

The trajectory also points toward improvement rather than a permanent ceiling. None of that erases the current cost. It does mean the direction of travel is toward wider deployability, not away from it.

The legal and regulatory environment evolving around SMPC-style computation

The legal questions around SMPC are not settled, and firms adopting the technology now are operating somewhat ahead of formal guidance, which compliance teams should know going in. One European data protection regulator, in a recent blog post, names the core ambiguity without softening it: frameworks like the GDPR were built around the assumption that some single actor holds or controls a dataset, and cooperative computation of the kind SMPC performs breaks that assumption. Questions such as who counts as the controller when no single party can see the data, and whether the output of an SMPC computation still qualifies as personal data, are now reaching data protection authorities for an answer.

The standardization effort underway is the clearest positive signal that this gap is closing rather than widening. NIST's Privacy-Enhancing Cryptography project, through its First Call for Multi-Party Threshold Schemes, published the final version of NIST IR 8214C in January 2026. The call organizes the work across signing, public-key encryption, symmetric primitives, key generation, fully homomorphic encryption, zero-knowledge proofs, and auxiliary gadgets. That breadth across seven distinct technical categories signals a multi-year institutional commitment to building reference frameworks.

That same regulator's own position, coming out of the same workshop, is that clearing the remaining adoption barriers will take standardization, better usability, and collaboration across regulators, technologists, and industry together. For a buyer evaluating an MPC-based product today, the practical takeaway is that security certifications and a clear compliance posture are a baseline a vendor needs to meet. That baseline matters for the audit as much as it matters for the trust a firm places in the vendor relationship itself.

A permissioned, privacy-preserving relationship intelligence architecture in practice

Put the cryptography and the regulatory groundwork together, and what a firm actually builds or buys is not one product but a stack of separable decisions: where the data physically lives, how permissions get enforced, and what control the individual professional retains at every step.

The data layer is the foundation. Each firm's signals remain inside that firm's own permissioned environment, and the only thing that crosses the boundary between two firms is the computation itself, running under the PSI protocol described earlier, never the underlying data that feeds it.

The permission layer sits above that. Equally, whatever a firm surfaces at the institutional level needs to stay free of individual context when it reaches a counterparty. A shared contact can be named; the specific emails and calendar entries that led a system to flag that contact as a strong connection should not be. That distinction between personal relationship data, which stays private to the individual, and institutional relationship signals, which can participate in a permissioned computation, is the architectural choice that makes the whole system trustworthy to the people whose networks it is built on.

The PSI query layer runs on top of both. Intersection queries execute against the permissioned signals each firm has chosen to make available, producing the shared-contact result described earlier, which then feeds into each firm's own private scoring of path quality. What reaches a user at the end of that chain is a ranked introduction path, built on data that never left its origin and never crossed a boundary it wasn't authorized to cross. That is the shape of a cross-firm relationship intelligence system that two competing funds could actually agree to run together: the architecture no longer asks them to trust each other more than they did before.