Worked structure five · Transaction Architecture
A structure built to be used again.
The manager expects to do this kind of transaction repeatedly. Built one at a time, each produces a different chain, a different set of consents, a different process for the administrator, and no reusable answer to any question the last one raised.
Written as a type. No manager, counterparty, adviser, asset, value, vintage or date appears in it. What transfers to your own transaction is the shape of the problem.
Worked structures · fifteen rooms
- 01An existing platform
- 02An ineligible asset
- 03An investor class
- 04A narrow exit
- 05A repeatable structure
- 06A co-investment
- 07A continuation
- 08Unavailable security
- 09The seed terms
- 10A change of control
- 11Drawn elsewhere
- 12An in-kind distribution
- 13A change of domicile
- 14An investor's perimeter
- 15A strategy, no vehicle
01 · The transaction as it arrives
Worked structuresBuilding a structure that can carry a class of transactions and not only this one.
It arrives as one transaction. One asset, one term sheet, one structure paper, and a timetable that belongs to the asset rather than to the manager.
Somewhere in the same conversation there is a second sentence, said in passing: the manager expects to do four or five of these. That sentence is the whole of the problem, and it is the one nobody structures against.
One asset, with a counterparty who has a date. Beside it, a strategy paper describing a programme of the same thing. The first document has a deadline and the second does not, so the first is the one that gets structured.
The fund, its constitution, its tier, its domicile, its administrator and whatever facility it carries. All of it was settled before the class of transaction was described, and none of it is re-chosen for a programme that arrives later.
Everything beneath the fund. The chain for the first asset is drawn by people whose attention is on the first asset, and it is then copied, because copying is what happens to a drawing that closed once.
The second transaction is quoted at the price of the first, in weeks as much as in anything else. When the second costs what the first cost, nothing was reusable, and that is a design fact rather than an accident.
One transaction asks what holds this asset. A programme asks what holds the next four, and the second question is not the first one repeated.
02 · The structural problem
The asset is not the difficulty. The fourth transaction is.
A structure that works once and a structure that works five times are different designs, and the difference between them is settled before the first one is built.
- The structural problem
-
This is a repeatability problem rather than a transaction problem, and the two are solved at different altitudes. A manager who structures each transaction on its own facts ends up with a portfolio of bespoke chains that share nothing: no common governance, no common documentation, no common answer to the questions every one of them asked, and no way to tell a lender, an administrator or an incoming investor what the arrangement is in one sentence.
The problem to solve is therefore not what structure holds this asset. It is what underlying structure would allow this class of transaction to be done repeatedly, and which parts of it have to be re-decided each time because they genuinely change.
Bespoke chains do not fail loudly. Each one closes, and each was correct on the day it was drawn. The cost accumulates rather than arriving, and three parts of it are paid by every manager who builds one at a time.
The same question put to counsel, to the tax advisers and to the administrator on every transaction, answered from the beginning each time, because the last answer was recorded as an answer about an asset rather than about a pattern. The work is real and done properly. It is simply done again.
Two transactions structured six months apart, by different people, under different pressure, produce two different structures. Nobody chose the divergence and nobody recorded it. It is found by whoever has to describe the portfolio to a third party.
A lender, an incoming investor or a buyer asks what the arrangement is. A platform answers in one sentence and then opens the pattern. A portfolio of bespoke chains answers with a data room, and the difference is priced by the party who asked.
One question comes before all of it, and it decides whether a platform is worth building at all: what makes a set of transactions a class. Five things travel together. The asset type, the pair of jurisdictions, the instrument that carries the exposure, the kind of counterparty, and the route the cash takes home. Transactions that share four of the five are a class, and a pattern drawn for them holds. Transactions that share two are not a class, whatever the strategy paper calls them.
A platform drawn for transactions that are not in fact alike is the same mistake as the bespoke chain. It is only made earlier, and at more cost, and with more conviction.
03 · What binds
Three of the five are read from documents. Two are answered by people who will carry the pattern every quarter.
Sorted by source, because a constraint written into the fund's own constitution binds differently from one created by a registry's practice. The first is amendable by a vote at a price. The second is not amendable at all.
- The relevant constraints
-
Five, and the last two are the ones that decide whether the design is real.
The fund's constitution, which has to permit the platform layer and the borrowing at whichever level the platform carries it. The repeatability of the entity form: whether the same vehicle can be formed again on the same terms, at reasonable speed, in the place the design assumes. The treatment of a repeated structure, which is a question for tax advisers and is asked about the pattern rather than about one transaction. The administrator's process, because a structure that needs a bespoke reporting arrangement each time is not a platform. And the governance the manager can actually run: a platform with more boards than the manager has people is a design that fails on the third transaction rather than the first.
Each of the five has a source and a moment. The source decides who can move it. The moment decides what it costs to have missed it.
The permitted-investment definition and the borrowing limit are read against a layer that did not exist when they were drafted. Both are amendable at a price the register sets, and the price rises once the amendment is asked for with a transaction behind it.
The first entity was formed under conditions nobody recorded: an approval that came quickly, a name that was available, a local participant who agreed. Whether those conditions repeat is a general question about a place and its practice, and it is put as one rather than inferred from having worked once.
A position taken about one transaction is a position about one transaction. A pattern claims it every year, for every entity formed under it, and the evidence has to exist separately for each.
The administrator answers in the only language that binds: whether what is proposed sits inside its standing process or outside it. Inside, it repeats. Outside, it is an exception, and exceptions are carried by individuals.
Boards need people who can attend them, read the papers and decide in the place they sit. Where the design needs more of those people than the manager has, the failure is quiet: minutes prepared in one place and signed in another, and a residence position that depends on the opposite.
None of the five is discovered by drawing the structure. All five are answered by asking somebody, and every one of them is cheaper to ask before the first transaction than after the second.
04 · The architectures considered
Holding chainsThree ways to carry a class of transactions, and the dull one survives.
Not three versions of one answer. Each does something different to what is shared, what is repeated, what a counterparty has to accept and what the fifth transaction costs.
- The architectures considered
-
Three. A flat structure in which the fund holds each transaction entity directly and nothing is shared. A platform entity beneath the fund holding every transaction entity, with governance, borrowing and reporting consolidated at the platform. A cell or series arrangement, in which one legal person carries segregated compartments.
The flat structure is the cheapest to start and the most expensive by the fifth transaction. The cell arrangement is the most elegant on paper and the one that most often meets a counterparty who will not accept segregation as a matter of contract in a jurisdiction that has not tested it. The platform entity is the least interesting of the three and the one that survives, for the reason most durable structures survive: every party to it already understands what it is.
The same three, read across the four dimensions that decide between them.
Shared: nothing but the fund. Repeated: everything, including the questions. What a counterparty accepts: nothing unusual, which is this route's one real advantage. Where it ends: at the transaction on which the manager can no longer describe its own portfolio in one sentence.
Shared: governance, borrowing, reporting and the administrator's process. Repeated: the transaction entity and the three matters attaching to each asset. What a counterparty accepts: a form it has seen before, held by a party it can identify, in a place it can check. Where it ends: nowhere in particular, which is the point of it.
Shared: the legal person itself. Repeated: a compartment. What a counterparty accepts: that segregation between compartments holds against it, in whatever forum the question would be argued. Where it ends: at the first counterparty that will not accept that. An untested question is priced by the party asked to carry it.
The route that survives, drawn in full. The two zones, and the accented line is the only connection that is re-decided every time.
05 · The critical dependencies
A dependency tested against the first transaction tells you nothing about the second.
Three, each with a party against it and a moment by which it has to be true. A dependency with no owner is a hope with a deadline on it.
- The critical dependencies
-
Three, and each is tested against the second transaction rather than the first.
That the platform entity can carry borrowing on terms a lender will accept across a portfolio it cannot yet see. Owned by the manager with its lender, and answered before the first transaction rather than at the third.
That the transaction entity form can be formed again, at speed, in the place the design assumes, and that nothing about the first one depended on a condition that will not repeat. Owned by local counsel, and confirmed as a general answer rather than as an answer about one entity.
That the administrator can run the platform as a standing process rather than as a series of exceptions. Owned by the administrator, agreed in the service documentation, and priced before the pattern is committed to.
Each of the three is a general question early and a particular question late. What late looks like, in the same order.
The lender documented against one asset it could see and diligence. Asked to extend across a portfolio it cannot, it reopens settled terms on its own timetable, with a signed transaction standing behind the request. The question is identical to the one that could have been asked at the outset. Only the leverage in the room has changed.
The second formation meets a condition the first did not: a name, an approval, a participation requirement, a change of practice at the registry that was never published. The pattern is now two patterns, both of which have to be documented and run.
The administrator took the first transaction as an accommodation and the second as an exception. By the third, the standing process is a set of exceptions carried in one person's memory, and the reporting timetable depends on that person being available.
None of the three belongs to us. The design states each as a question with a party against it and a date beside it, so that it is asked while it is still a general question about a pattern rather than an urgent one about a transaction.
Every one of the three is answerable in the weeks before the first transaction, by somebody already appointed. Each of them costs a timetable when it is asked at the third.
06 · The architecture that survives
The blueprintThe design is not the boxes. It is the line drawn across them.
Above the line, questions settled once and not reopened. Below it, questions asked at every transaction because the honest answer changes. Sorting a question into one of the two is the work, and it is done before the first transaction rather than during the third.
- The architecture that survives
-
Two zones, and the whole design is the line between them.
Above the line, built once and not reopened: the fund, its constitution, its tier and its domicile, and beneath it a platform holding entity carrying one governance arrangement, one borrowing relationship, one administrator process and one reporting standard. Below the line, repeated per transaction: a transaction entity of a single settled form, holding one asset, formed on a documented pattern.
What is deliberately left open is the connection between the two. Each new transaction entity is admitted to the platform on its own consents, its own local ownership confirmation and its own security arrangement, because those three genuinely change from one asset to the next and a platform that pretends otherwise is a platform that will be wrong once, expensively. The design names that line explicitly so that the manager knows which questions are settled and which are asked again.
Eight questions, sorted. The sorting is written down, and being written down is what makes it a design rather than a habit.
Settled once, from the constitution, before the platform entity is formed. If the answer is no it is a vote, and a vote taken early costs less than one taken with a transaction behind it.
Settled once, at the platform. A lender that documents a platform-level arrangement documents it again on the same terms. A lender asked afresh on every transaction prices every transaction afresh.
Settled once. One board, one calendar, papers to one standard, decisions recorded where the design says they are taken. Governance invented per transaction gets skipped on the one in a hurry.
Settled once, in the service documentation. The test is whether a new transaction entity joins the reporting cycle without anybody negotiating anything.
Settled once, as a pattern with the parts that vary marked as variable. Re-choosing the form per asset is the cost the platform was built to remove.
Asked again. Pre-emption rights, transfer provisions, change-of-control clauses and licence conditions belong to the asset and its own contracts, and no two assets carry the same set.
Asked again, of local counsel, per asset. The answer is about a register in a country and that register's own requirements of a foreign shareholder.
Asked again, and it is the question the pattern makes it possible to ask. A transaction that does not fit is not a reason to widen the pattern. It is a reason to structure that one separately.
The line is a document the manager holds, naming which zone each recurring question sits in and who answers it there. An upper-zone question is answered by a decision already taken. A lower-zone question goes to a named party every time, and the pattern says which.
A structure nobody has to think about twice is not a simple structure. It is a structure whose thinking was done once, in the open, by people who wrote down what they decided.
07 · The implementation framework
How an engagement runsThe order is the design. A platform is built before it is needed, or it is not built.
Written as dependency statements rather than tasks, because the sequence is the part that is easy to get wrong and expensive to correct.
- The implementation framework
-
Build the platform layer before the second transaction, not after the fourth. Settle the transaction entity form as a documented pattern, with the parts that vary marked as variable. Agree the administrator's standing process and the lender's platform-level arrangement before either is under transaction pressure. Then take the first transaction through the pattern deliberately slowly, because the first one is the test of the pattern and not merely the first use of it.
What follows belongs to the manager and its appointed parties, and the platform exists to make their work repeatable rather than to replace it. Counsel documents the pattern once and applies it thereafter. The tax advisers take the treatment of the pattern rather than of each transaction, which is the saving the platform actually delivers. The administrator adopts the standing process. The lender documents at the platform level. We design the two zones, mark the line between them, and stress-test the pattern against the transactions the manager has not done yet.
The same sequence, written as the four statements that hold it in order.
Do not form the platform entity until the permitted-investment definition and the borrowing limit have been read against it word by word, at the level the platform will actually carry the borrowing.
Do not settle the transaction entity form until local counsel has answered the repeatability question as a general question about the place, rather than as a report on the entity that was formed first.
Do not take the first transaction through the pattern until the administrator's standing process is in the service documentation and the lender's platform-level arrangement is drawn. Both parties answer differently when there is no signed transaction in the room.
Do not take the second transaction through the pattern until the first has been run against it and every departure recorded with a decision beside it: either the pattern was wrong, or that transaction was. An unrecorded departure is neither.
What is handed over is a pattern rather than a drawing. It carries the transaction entity form with the fields that vary marked as variable, the standing list of consents to be identified on every asset with the party who answers each, the admission steps by which a new entity joins the platform, and the lower-zone questions written as questions, so that asking them is a step rather than an act of memory.
08 · What this case generalises to
Any question asked twice is a design question the second time.
The two zones are not a fact about platforms. They are the shape of every arrangement a manager intends to use more than once and has structured only once.
The allocation rule, the vehicle form and the terms on which an interest is offered are settled once, before an asset exists to test them. Which holders are offered each one, and what consents travel with the asset, are asked again every time.
The level at which the facility attaches, the form of the security package and the party who grants it are settled once. What is actually secured, in which country and on which register, is asked again. A lender that has documented the upper zone once documents the lower zone quickly, and that is where the timetable is won.
What a successor vehicle inherits is a pattern rather than a set of documents. A manager that never wrote one down re-draws the first fund from memory, under time pressure, while raising.
One thing does not generalise. A platform is not a general-purpose vehicle and a pattern is not a policy. Both are drawn for a class and hold inside it, and the discipline that makes them worth having is the willingness to say a transaction sits outside. The manager that keeps widening its pattern arrives back where this case began, having paid for the platform on the way.
Written as a type · stated as at August 2026
A platform is not a bigger structure. It is a smaller number of questions, asked once, and a named list of the ones that are asked again.
Write to us.
Complex transactions fail at the interfaces between otherwise workable components. We resolve the structural complexity between investment intent and transaction execution.
Write to us