The deal graph: How knowledge Ggraphs change the way banks execute complex transactions
Picture a hypothetical transaction. Group A is acquiring a significant equity stake in Company B. On the buy side there is a lead bank, a syndicate of co-lenders, two financial advisors, a legal firm coordinating across four jurisdictions, and an independent valuation firm. On the sell side, a different advisor, a different legal team, and a set of existing shareholders with their own legal representation. Regulatory filings are required in three countries. The lead bank has existing relationships with entities on both sides of the deal.
This is not an unusual transaction. It is, by the standards of institutional finance, fairly routine. And yet the information required to execute it well; to understand who is involved, what role they are playing, how they are connected to each other and to the bank’s existing book, and what obligations flow from those connections is almost certainly scattered across a CRM, several deal management systems, a document repository, email threads, and the institutional memory of the senior bankers involved.
The question is not whether banks can execute deals under these conditions. They clearly can and do so every day. The question is what it costs them to do so, and what they miss when the information isn’t connected.
Why deal structures are hard to model
The core problem is that a transaction like this is not a collection of facts. It is a network of relationships, and those relationships are contextual. The same law firm might be legal advisor to the acquirer on this deal and to a portfolio company of the target on a different one, a conflict that matters enormously but only becomes visible when you can see both relationships simultaneously.
The same bank that is leading the acquisition financing may also hold a debt position in the target company’s parent group. That is a relationship between the bank and the transaction that affects pricing, internal approvals, and regulatory disclosure, but only if someone can see it.
Individual parties shift roles depending on where you look. An advisor who introduced the deal may also be a shareholder in the acquiring vehicle. A co-lender may be a competitor in other mandates. The financial model values an asset that the bank has separately underwritten in a different structure.
None of these connections are hidden. They exist in the ether somewhere. The problem is that the data is organised around records and documents rather than around the relationships themselves. So the connections only become visible when someone already knows to look for them.
What changes when you model the deal as a graph
A knowledge graph inverts this. Instead of storing documents and records and inferring connections at query time, you store the relationships themselves – typed, attributed, and queryable – alongside the entities they connect.
In a deal graph, the acquisition structure is not a document or a database row. It is a set of entities – acquirer, target, financing parties, advisors, regulators, existing shareholders – connected by typed relationships that carry the attributes that are relevant. The advisory mandate has a start date, a fee structure, a scope. The lending commitment has a facility size, a tenor, a seniority. The shareholder relationship has a percentage, a class of share, and a governing agreement. The legal representation covers specific jurisdictions and counterparties.
Once the deal is modelled this way, the questions that previously required manual investigation become straightforward queries. Which parties in this transaction have existing relationships with the bank? Are any of them on opposite sides of a current mandate? Does any entity in the acquiring structure appear in our sanctions watchlist, at any degree of separation? What disclosure obligations does the bank’s existing debt position in the target group create?
These are all standard questions that every deal team needs to answer, and in most institutions they are answered through a combination of manual searches, relationship manager knowledge, and compliance processes that run in parallel to the deal rather than alongside it.
TypeDB and the semantics of a transaction
Graph databases have existed long enough that the concept of storing relationships natively is no longer novel. The harder problem, and where most implementations fall short, is representing what the relationships mean, not just that they exist.
A transaction involves entities that play multiple roles simultaneously. The lead bank is a lender, a relationship manager, and potentially a shareholder in an entity related to the deal. An individual may be a director of the target, a beneficial owner of one of the acquiring vehicles, and a personal client of the bank’s private wealth division. In a conventional graph database, these roles are typically flattened: entity A is connected to entity B by an edge. The meaning of that connection (the role, the context, the conditions under which it applies) has to be managed outside the database.
TypeDB was built specifically to handle this kind of semantic complexity. Its type system allows roles to be defined as part of the relationship itself. A party does not just connect to a transaction; it participates in it as an advisor, a lender, a guarantor, a counterparty, and those roles carry different attributes and trigger different rules. The same entity can hold multiple roles simultaneously without the model breaking down.
When a conflict check runs in TypeDB, it is not simply a search across a flat list of names. It is a traversal of the relationship graph, respecting the roles and contexts that determine whether a connection is actually a conflict. When a regulatory disclosure requirement is triggered, TypeDB can infer which relationships create the obligation and surface them automatically, because the rules that govern disclosure are part of the model, not a separate compliance layer bolted on afterwards.
What deal teams actually get
For the bankers executing the transaction, the immediate difference is visibility. Rather than a deal management system that tracks documents and milestones, they have a live view of the entire deal structure; every party, every relationship, every obligation, that updates as the transaction evolves and that can be queried in plain terms.
For risk and compliance, the deal graph provides something that is increasingly difficult to maintain manually: a complete, auditable picture of the bank’s exposure and obligations at any point in time. When a new party joins the syndicate, the conflict and exposure checks happen against a model that already contains everything the bank knows about that party and their connections. When a regulatory filing is due, the information required to complete it is in the graph.
For relationship managers, the deal graph solves a critical business problem; context reduces with increasing numbers of and complexity of relationships. The relationships a senior banker carries typically live in their head and their inbox.
In the scenario that a key member of the team departs, a new coverage banker inherits a complete picture of how every relationship in their book connects to the bank’s broader activity. That is a meaningful commercial advantage, and it compounds over time.
When the transaction closes, the deal graph becomes an auditable trail and repository for future activity. The relationships it captured between entities, between parties, between the bank and its clients and counterparties, persist as structured data that informs the next mandate, the next conflict check, the next credit decision.
What are the tradeoffs to modelling this in a database?
Modelling a deal structure in TypeDB requires upfront schema design that a document management system does not.
However, over time, the framing that matters most is the cost of building it versus the cost of the status quo. Every institution that executes complex transactions is already paying for the absence of connected data, in the analysts who hold context in their heads, in the compliance processes that run serially, in the conflicts that surface late.
So, while there is an up-front spend to intentional ecosystem modelling, that initial cost is recovered again and again over time, with value continuing to grow as the model matures.
The deal graph moves that cost from an ongoing operational burden to infrastructure that gets more valuable with every transaction added to it.