Counterparty, Credit & Limit Modeling
Credit and limits are what stop a desk before it breaks. This course models counterparty exposure, collateral, and a limit framework, then builds a real-time checking service that enforces limits pre-deal and post-deal with breach alerts.
The pipeline at the heart of this course
Credit risk from the data up
Every trade creates an obligation, and every obligation carries the risk that the counterparty fails to meet it. Credit risk management is the discipline of measuring and bounding that risk, and this course builds it from the data model up: exposure, collateral, and the limits that cap how much risk the desk may take against any counterparty.
The course is practical about what exposure means as data. Current exposure is what you would lose if a counterparty defaulted today; potential future exposure models how that could grow. Both must be computed, aggregated across the legal-entity hierarchy, and compared against limits, and all of that is a data-engineering problem before it is a financial one.
The course grounds credit risk in data because that is where it is actually managed day to day, and the framing matters. Exposure is a computed quantity, limits are modeled boundaries, and a breach is a data event, and treating them this way is what lets risk be enforced automatically rather than checked by hand. The financial concepts matter, but the course's contribution is showing how they become a service the platform can run.
The exposure and collateral model
You model counterparty exposure across products, netting where agreements allow and aggregating up the legal-entity hierarchy so that exposure to related entities is seen together. Collateral and margin reduce exposure, and modeling them correctly, including the netting agreements that govern them, is essential to avoid overstating or understating risk.
Concentration and wrong-way risk get explicit treatment: exposure that clusters on one counterparty or correlates with that counterparty's own health is more dangerous than its headline size suggests. The data model has to surface these, not hide them in an aggregate.
Modeling exposure correctly means modeling what reduces it as well as what creates it, and the course is careful about both. Collateral, margin, and netting agreements can dramatically change the real exposure, and a model that ignores them overstates risk and wastes capacity, while a model that mishandles them understates risk dangerously. You learn to represent these agreements so that the exposure number reflects the true economic position.
The limit framework
Limits are the controls that turn risk appetite into enforced boundaries. This course models the limit hierarchy, notional limits, tenor limits, potential-future-exposure limits, set at counterparty, desk, and portfolio levels, and computes utilization and headroom against them in real time. The limit model has to mirror the organizational hierarchy so that a breach at any level is caught.
You learn the difference between pre-deal checks, which prevent a limit-breaching trade from being done, and post-deal monitoring, which catches breaches from market moves after the fact. Both are necessary, and both depend on exposure that is computed fast enough to matter.
The limit framework has to mirror the organization, and the course builds it that way so that a breach is caught at whatever level it occurs. Limits at counterparty, desk, and portfolio level, of different types, form a hierarchy, and utilization has to be computed against all of them at once. The course shows how to model this so that a single check can answer whether a trade breaches any limit in its scope.
Real-time limit checking
A pre-deal limit check that takes thirty seconds is useless on a fast desk. This course builds a checking service architected for speed: exposures precomputed and cached, incremental updates as trades and markets move, and a check path that answers in milliseconds. The connection to the streaming course is direct, real-time limit checking is a streaming problem.
Breach detection and escalation are modeled as data: when utilization crosses a threshold, a breach event is raised, routed, and audited. Overrides, where a breach is consciously accepted, are recorded with authority and reason, because an unaudited override is a governance failure waiting to surface.
Real-time checking is where the course connects most directly to the streaming module, because a pre-deal check that cannot answer in the time a trader will wait is not a control at all. The design, precomputed exposures, incremental updates, a fast check path, is what makes enforcement possible on a live desk. The course also shows how the fast pre-deal check and the complete post-deal check stay consistent, so nothing slips through the gap between them.
A limit-management service end to end
The course assembles these into a service: model exposure, model limits, compute utilization, check pre-deal and post-deal, and alert on breaches, with the auditability that risk and regulators require. You leave able to build the control layer that lets a desk trade fast without trading blind.
The artifact below shows the exposure and limit model and a real-time utilization check, the query that runs before every deal.
The auditability of the whole thing is what makes it acceptable to risk and regulators, and the course does not treat it as optional. Breaches, escalations, and overrides are all recorded with authority and reason, so that a consciously accepted breach is a documented decision rather than a silent gap. You finish able to build a limit service that lets a desk trade fast while keeping the controls, and the record of them, that trading demands.
Real-time checking and the cost of being slow
A limit check that is correct but slow is, on a fast desk, effectively useless, because a pre-deal check that takes many seconds either blocks trading or gets bypassed. This course therefore treats performance as a first-class requirement, not an optimization. Exposures are precomputed and cached, updated incrementally as trades and markets move, so that the check itself is a fast lookup and comparison rather than a heavy recomputation.
You learn the architecture that makes this possible: maintaining current exposure per counterparty and per scope in a fast store, updating it in response to each new trade and each market move, and structuring the limit check so that it consults this precomputed state. The connection to the streaming course is direct, real-time limit checking is fundamentally a stateful streaming problem, and the two courses reinforce each other.
The course is also honest about the trade-offs. Precomputed exposure is fast but must be kept consistent with the trades that drive it, and a cache that drifts from reality produces checks that are worse than useless because they are confidently wrong. Managing that consistency, knowing how stale the cached exposure may be and bounding it, is part of doing real-time risk correctly.
Breaches, overrides, and auditable control
Limits exist to be enforced, but the enforcement must be governed, because a limit system with no controlled way to handle breaches and overrides becomes either a straitjacket or a fiction. This course models breach detection and escalation as data: when utilization crosses a threshold, a breach event is raised, routed to the right people, and recorded. Nothing about a breach is informal or untracked.
Overrides, where a breach is consciously accepted for a good reason, are modeled with the same rigor: who authorized the override, on what authority, for what reason, and for how long. An unaudited override is a governance failure waiting to surface in an incident review, and the course designs the data model so that every override leaves a complete, queryable trail. This is exactly the kind of control the regulation-and-conduct concerns of the wider domain demand.
By the end you can build a control layer that lets a desk trade fast without trading blind, and that can demonstrate to risk and to regulators exactly how its limits were set, checked, breached, and overridden, with a full audit trail behind every decision.
Where this course sits, and what it unlocks
Credit and limits is the seventh course, adding the controls that keep a desk safe over the exposures derived from positions. It consumes the position and counterparty data from earlier courses and produces the limit checks that the streaming course runs in real time and the STP capstone embeds inline in the automated flow.
The real-time checking architecture you build here is fundamentally a stateful problem, which is why it pairs so naturally with the streaming course, and the audited breach-and-override model is exactly the kind of control the automated STP flow requires to be safe.
Common credit-and-limit failures, and how to avoid them
The classic failure is a limit check that is correct but too slow to run before a deal, so it is either bypassed or it blocks trading; precomputed, incrementally updated exposure is what makes the check fast enough to be real. A second failure is a stale exposure cache that drifts from the trades driving it, producing checks that are confidently wrong, which is worse than no check; bounding and managing that staleness is essential.
A third failure is ungoverned overrides, accepting a breach with no audit of who authorized it and why, which becomes a governance problem the moment an incident is reviewed. Modeling breaches and overrides as audited events prevents this. The course names each pattern and gives the design that avoids it.
By avoiding these patterns you get a control layer that lets a desk trade fast without trading blind, and that can prove exactly how every limit was set, checked, and overridden.
A worked example: a pre-deal check that blocks a trade
Follow a trade that would breach a limit. A trader prices a new deal with a counterparty; before it can be booked, the pre-deal check runs. The service looks up the counterparty's current exposure from its precomputed store, adds the incremental exposure the new trade would create, and compares the projected total against every limit in scope, counterparty, desk, and portfolio.
The projected exposure exceeds the counterparty limit, so the check returns a would-breach result and the deal is blocked, or routed for an authorized override, before it is ever booked. The whole check completes in milliseconds because the exposure was precomputed, not recalculated from scratch. The worked example runs the exact query shown earlier and shows the breach being caught at exactly the right moment, before the risk is taken.
This demonstrates the course's core claim: a limit system is only useful if it is both correct and fast enough to run before the deal, and precomputed, incrementally maintained exposure is what makes that possible.
Operational realities: consistency, escalation, and audit
Operationally, the precomputed exposure must stay consistent with the trades and markets that drive it, because a cache that drifts produces checks that are confidently wrong. The course covers keeping the exposure store current through incremental updates and bounding how stale it may be, so the checks stay trustworthy under real-time load.
Escalation and audit are the other operational pillars. A breach must be routed to the right authority, and an override must be recorded with who approved it, why, and for how long, so that every exception is defensible in a later review. The course designs these as audited events, so that the limit system can not only control risk in the moment but also prove, after the fact, exactly how every limit was managed.
Design trade-offs: pre-deal latency versus completeness
A pre-deal limit check lives on the critical path of trading: it must answer before a trade is done, in the time a trader is willing to wait, which is almost none. That budget forces a trade-off against completeness. A perfectly complete check would recompute full potential future exposure across every product and agreement for the counterparty, but that is far too slow to sit in front of a deal. A fast check uses precomputed, cached exposures and an incremental estimate of the new trade's impact, accepting some approximation for speed.
The course teaches how to make that approximation safe: precompute the expensive parts, update them incrementally as the streaming course describes, and reserve the full recomputation for post-deal monitoring where latency is not critical. The design accepts that the pre-deal check is a fast, conservative gate and the post-deal check is the complete one, and it makes sure the two are consistent so that nothing slips through the gap between them.
Carrying credit and limits into the capstone
Credit and limit checking is the control stage of the STP flow, and it is the stage with the most consequential exception path: a limit breach does not just flag a trade, it can stop it. The inline check you build here is what lets the capstone enforce risk appetite automatically, and the audited override mechanism is what lets a breach be consciously accepted without breaking the audit trail.
Because this stage can block the flow, its speed and correctness directly shape the straight-through rate and the platform's safety at once. A check too slow to sit inline forces trades out of the automated path; a check too loose lets risk through. The real-time architecture you build here is what lets the capstone be both fast and controlled, which is the whole promise of straight-through processing done responsibly.
Performance and scale considerations
The pre-deal limit check lives on the critical path of trading with almost no latency budget, so performance is not a refinement here but a defining constraint, and the course designs around it. Exposures are precomputed and cached, updated incrementally as trades and markets move, so that the check itself is a fast lookup and comparison rather than a heavy recomputation. The connection to the streaming course is direct: keeping exposures current at speed is a streaming problem.
At scale, exposure must be aggregated across products and up the entity hierarchy for many counterparties at once, which is where graph models and careful caching earn their place. The course shows how to keep aggregated exposures fresh enough to be correct and fast enough to be checked in front of a deal, which is the balance the whole limit service is built around.
Testing and validating limit checks
A limit service's correctness is safety-critical, so the course tests it directly: construct a trade that should breach a limit and confirm it is blocked, construct one that should not and confirm it passes, and confirm that a market move which pushes utilization over a threshold raises a breach. These are concrete, assertable scenarios, and building them is how you gain confidence the control actually bites.
The course also teaches validating the consistency between the fast pre-deal check and the complete post-deal recomputation, because a gap between them is exactly where risk slips through. Reconciling the two, and testing that a breach caught post-deal would also have been flagged pre-deal where the data allowed, is how you confirm the control has no blind spots. You finish able to demonstrate that the limit framework enforces what it claims to.
How it works, concretely
-- Limits set at multiple levels of the hierarchy
CREATE TABLE credit_limit (
limit_id bigint PRIMARY KEY,
scope_type text NOT NULL CHECK (scope_type IN
('COUNTERPARTY','DESK','PORTFOLIO')),
scope_id bigint NOT NULL,
limit_type text NOT NULL CHECK (limit_type IN
('NOTIONAL','TENOR','PFE')),
amount numeric(20,2) NOT NULL,
currency char(3) NOT NULL
);
-- Current exposure, maintained incrementally as trades/markets move
CREATE TABLE exposure (
scope_type text NOT NULL,
scope_id bigint NOT NULL,
current_exposure numeric(20,2) NOT NULL,
potential_future numeric(20,2) NOT NULL,
as_of timestamptz NOT NULL,
PRIMARY KEY (scope_type, scope_id)
);
-- Pre-deal check: would this trade breach any limit in scope?
SELECT l.limit_id, l.scope_type, l.amount,
e.current_exposure + :incremental_exposure AS projected,
(e.current_exposure + :incremental_exposure) > l.amount AS would_breach
FROM credit_limit l
JOIN exposure e
ON e.scope_type = l.scope_type AND e.scope_id = l.scope_id
WHERE l.scope_id IN (:counterparty_id, :desk_id, :portfolio_id);
-- If any row has would_breach = true, the deal is blocked or escalated.Chapters 121 to 140
Twenty sequential chapters. Within the full bundle these are chapters 121 through 140 of 240.
- 121Credit risk in trading, from the data upApproaching credit risk as a data and modeling problem. Credit risk is a data problem before it is a financial one, and the course builds it that way.
- 122The counterparty exposure data modelModeling counterparty exposure across products. The exposure model is what quantifies how much could be lost if a counterparty defaulted.
- 123Current exposure and potential future exposureComputing current exposure and potential future exposure. Current and potential future exposure answer today's loss and how it could grow.
- 124Collateral, margin, and netting agreementsModeling collateral, margin, and netting agreements. Collateral and netting reduce exposure, and modeling them wrong misstates real risk.
- 125The legal-entity and credit hierarchyAggregating exposure up the legal-entity and credit hierarchy. The credit hierarchy is what lets exposure to related entities be seen together.
- 126Limit types: notional, tenor, and PFEDefining notional, tenor, and PFE limit types. Different limit types cap different dimensions of the risk a desk may take.
- 127The limit data model and hierarchyDesigning the limit data model and its hierarchy. The limit hierarchy mirrors the organization so a breach at any level is caught.
- 128Limit utilization and headroom computationComputing limit utilization and available headroom. Utilization and headroom are what tell a desk how much room it has left.
- 129Pre-deal vs post-deal limit checksDistinguishing pre-deal from post-deal limit checks. Pre-deal checks prevent a breach; post-deal monitoring catches breaches from market moves.
- 130Real-time limit checking architectureArchitecting limit checks that answer in real time. Real-time checking is a streaming problem, connecting this course to the streaming one.
- 131Breach detection and escalation dataModeling breach detection and escalation as data. Breach detection and escalation are modeled as data so they are auditable.
- 132Wrong-way risk and concentrationSurfacing wrong-way risk and concentration. Concentration and wrong-way risk are more dangerous than headline exposure suggests.
- 133Settlement risk and Herstatt exposureHandling settlement risk and same-day exposure. Settlement risk is a distinct exposure that the model must not overlook.
- 134Credit valuation adjustment data needsSourcing the data a credit valuation adjustment needs. The data behind credit valuation adjustment feeds pricing and risk alike.
- 135Aggregating exposure across productsAggregating exposure consistently across products. Aggregating exposure across products is what gives a true counterparty-level view.
- 136Graph models for entity relationshipsUsing graph models for entity relationships. Graph models capture the entity relationships that flat tables struggle to express.
- 137Caching exposures for fast checksCaching exposures for millisecond checks. Caching exposures is what makes a pre-deal check fast enough to sit in front of a trade.
- 138Auditing limit changes and overridesAuditing limit changes and overrides. Auditing overrides is what keeps a consciously accepted breach from becoming a control gap.
- 139Stress testing exposure and limitsStress testing exposure and limits under shock. Stress testing shows how exposure and limits behave under adverse scenarios.
- 140A limit-management service end to endAssembling a limit-management service end to end. You finish with a limit service that lets a desk trade fast without trading blind.
What you'll be able to do
- Model counterparty exposure, collateral, and netting
- Design a limit hierarchy and compute utilization in real time
- Enforce pre-deal and post-deal limit checks at low latency
- Model breaches and overrides with a complete audit trail
- Stress test exposure and limits under shock
Audience & prerequisites
Engineers building the credit and limit controls that keep a desk safe, and risk-technology teams who need those controls fast and auditable.
Prove the module by building it
Build a limit-checking service: model exposures and limits, compute utilization in real time, and enforce pre-deal and post-deal limit checks with breach alerts.
This course project is one of twelve that culminate in the bundle's end-to-end capstone, a complete working ETRM data platform run as a straight-through pipeline.
Learn it your way
This course is included in the ETRM Data Engineering and Analytics bundle, available self-paced with PDF handbooks, slide decks, video explainers, and hands-on labs and a project, and deliverable as private corporate training.
Explore the full 12-course bundle and its end-to-end capstone project →
Frequently asked questions
What does the Counterparty, Credit & Limit Modeling course cover?
Modeling credit exposure, collateral, and the limit framework that stops a desk before it breaks. It runs to 20 sequential chapters (chapters 121 to 140 of the 240-chapter bundle).
Where does this sit in the learning path?
It is course 7 of 12 in the ETRM Data Engineering and Analytics sequence. It builds on the courses before it and prepares for those after it.
Is there a project?
Yes. Build a limit-checking service: model exposures and limits, compute utilization in real time, and enforce pre-deal and post-deal limit checks with breach alerts.
What technologies are involved?
The course works with SQL, Graph model, Python, Rules engine, Redis, chosen to reflect how real ETRM data platforms are built.
Is it available self-paced?
Yes. Every course in the bundle is available self-paced with PDF handbooks, slide decks, video explainers, and hands-on labs and a project, with lifetime access.
Can my team take it as corporate training?
Yes. The whole bundle, or individual courses, can be delivered as private corporate training mapped to your stack and data. Use the contact form to scope it.
Take this course, or the whole platform
Enroll self-paced, or bring the ETRM Data Engineering bundle to your team.