Prime Brokerage Business Information Model

The Same Position, Counted Three Different Ways

Prime Brokerage Business Information Model is a structured inventory of the business data entities a prime broker runs on — client, fund, account, position, margin requirement, collateral, loan, locate, corporate action — organized into foundational, transactional and informational layers, in an editable Word document with a guide to business data modeling.

A prime broker sees the same position from several angles at once: as a settled holding, as a margin input, as collateral available to finance, and as inventory available to lend. Each view has its own timing and its own eligibility rules, and a position that is fully present in one may be unavailable in another.

The client structure is layered too. A management company runs several funds, each with several accounts, some cross-margined and some not. Whether an exposure question is asked at manager, fund or account level changes the answer, and most systems only model one of the three cleanly.

This model states those layers and views explicitly. It is a business information model rather than a database design — it names what the business means, which is what has to be settled before any margin or financing logic can be reasoned about.

The Distinctions This Is Meant to Make

Three definitional problems that make prime brokerage data unusually layered.

Manager, fund, or account? Credit is extended at one level, margin computed at another, and reporting delivered at a third. Cross-margining agreements cut across all of them, and only an explicit hierarchy keeps the answers consistent.

Which position is the position? Traded, settled, margin-eligible, collateral-eligible and lendable are different quantities for the same holding at the same moment. Modeling them separately is the point.

Collateral, or just an asset? An asset becomes collateral through eligibility, haircut and legal arrangement. Where those live as attributes rather than entities, optimization is guesswork.

Why This Matters Now

Balance sheet scarcity has made the modeling questions financial rather than architectural.

Collateral Optimization Requires Eligibility as Data

Choosing what to pledge where is only computable when eligibility rules and haircuts are modeled rather than embedded in a spreadsheet or a person's judgment.

Client Profitability Is Asked at Manager Level

Revenue is booked per account and reviewed per relationship. Rolling one up to the other needs the hierarchy to exist as an entity, not as a naming convention.

Shorter Settlement Puts Pressure on Position Views

When affirmation and borrow windows shrink, the difference between a traded and a settled position stops being academic.

What Is Included

Two files:

Who This Is Built For

This model pairs with the Prime Brokerage Capability Model, which states what a prime broker does; the information model states what it does it to. Neither substitutes for the other.

How to Put It to Work

• Make the manager, fund and account hierarchy explicit, including cross-margin groupings.
• Name each position view separately rather than treating position as one number.
• Model eligibility and haircut as entities so collateral decisions become computable.
• Use it as the firm-owned target when mapping a vendor platform's structures.

Where Prime Brokers Typically Start

What You Are Actually Buying Is Time

Building this internally means definitional sessions with operations, credit and financing — groups whose day is governed by an overnight cycle that does not pause for workshops.

• The first draft is the expensive part. Reviewing a proposed set of entities is a different task from inventing one, and a much shorter one.
• Disagreement becomes visible immediately. A written definition of position surfaces the operations-versus-risk gap in the first session.
• It outlives the project that prompted it. The same model serves a collateral program, a profitability analysis, and a platform change.

Those first two columns describe what comparable efforts tend to involve, not a quoted benchmark — your figures depend on scope and who does the work.

Built From Real Engagements

We are software entrepreneurs and business consultants who have delivered business architecture and transformation work across financial services firms. This model is the distilled, reusable output of that work rather than a theoretical exercise — which is also why it carries the limits described below.

An Honest Note on Fit

This is a generic model designed as a starting point. Customization is expected, not a sign that something went wrong.

Specifically:

Terms You Should Know Before Purchasing

Read the description above in full before you buy. Delivery is immediate and the files are yours to keep, which is also why we cannot take returns, issue refunds, or swap a purchase for a different product once it has been downloaded. What you receive is what is listed — no warranty beyond that, and no bundled customization, implementation help, or support. A Enterprise License covers everyone inside one organization; if you intend to reuse the material across several clients, the Consultancy License is the one you need. The full digital product terms govern the sale.