A counterparty risk system is the software an asset manager uses to review, rate, limit and monitor the banks, brokers and futures commission merchants it trades with, and to keep the evidence of who decided what. What it needs from the firm is mostly policy and lists the firm already has: its rating scorecard, its limit grid and approval rules, its approved counterparty list, a feed of exposure by fund and product, and a sample of past reviews to test against. What it should not need is a team retyping filings into it. Botminds' Counterparty Risk Management collects each counterparty's annual reports, Pillar 3 disclosures and regulatory filings from public sources in their own language, so switching it on is mostly a matter of loading the firm's rules and connecting the systems that hold exposure and limits.
What switching on looks like, on the sample firm
412
banks and brokers on the approved counterparty list, reviewed every year
5
scorecard drivers with the firm's own weights, versioned
2tests
for every limit: the grid by notch and a capital test on the counterparty
<4hours
per annual review: the design target once running
What is a counterparty risk system?
A counterparty risk system holds the firm's view of every counterparty, its review, rating, limit and the evidence behind them, joins it to live exposure, and routes each decision to the person allowed to make it. Bank supervisors describe the bar for the systems behind counterparty risk: they should be "commensurate with the size and complexity of counterparty exposures", and firms "should aim to reduce the number of systems involved in exposure measurement and management in order to reduce operational risk" (BCBS, CRI40.119, 40.121).
For an asset manager the system's job is narrower than a dealer bank's and wider than a spreadsheet's. It does not price trades or calculate potential exposure; the risk engine does. It does carry the credit side end to end: the filings, the spread, the rating case, the limit proposal, the approvals, the watch between reviews and the report to the risk committee.
What data does a counterparty risk system need?
A counterparty risk system needs the firm's credit policy as settings, its list of counterparties with their legal entities, a daily feed of exposure, read access to its limit system, and a set of past reviews to check against. None of these is new data; each exists somewhere in the firm already, often in a spreadsheet or a policy document.
What you bring to switch on a counterparty risk system, who owns it and what it takes
- The rating scorecard
Drivers, weights, the notch scale and how scores map to notches. Owner: head of counterparty risk. Effort: a policy document turned into settings.
- The limit grid and capital tests
Maximum limit by notch and counterparty type, plus any test on the counterparty's capital. Owner: credit policy. Effort: one table.
- Approval rules and roles
Who prepares, who approves up to what amount, who co-signs above it, who may see limits. Owner: CRO. Effort: a delegation-of-authority table.
- The approved counterparty list
Legal entities, groups and identifiers, products and funds allowed, current rating, limit and review date. Owner: counterparty risk with operations. Effort: an export from the counterparty master.
- Exposure feeds
Exposure by counterparty, fund and product, gross and net of collateral, at least daily. Owner: risk technology. Effort: a connection to the risk engine.
- Country ceilings and peer library
Any cap on ratings by country, and the peer groups the firm already uses. Owner: credit research. Effort: two lists.
- A sample of past reviews
Twenty or so signed reviews, including a few hard ones, to test the agents' ratings against the committee's. Owner: head of counterparty risk. Effort: a folder.
- Residency and retention choices
Where data is held and how long the audit trail is kept. Owner: compliance and IT. Effort: decisions, not data.
What you don't bring: the filings
The filings the reviews are built from do not have to come from the firm. Banks publish annual reports and Pillar 3 disclosures on their own sites, regulators publish data series, and since January 2026 the European Banking Authority's Pillar 3 data hub holds "prudential information from all EEA institutions" on "a single, harmonised digital platform" (EBA). In Counterparty Risk Management the Filing Intake agent collects annual reports, Pillar 3 disclosures, broker and futures broker reports and audited statements from investor relations sites, regulator sites, the firm's document management and its data vendor, and detects each file's language, period and accounting basis.
Some documents only the firm can supply: a broker's FOCUS report shared under a confidentiality agreement, a bank's response to a questionnaire, notes from a due diligence call. Those go into the same file through document management. What changes is the default. The analyst no longer starts a review by downloading and retyping; he starts it on a spread already cited to its pages, which is the subject of counterparty due diligence in the bank's own language.
Switching on a counterparty risk system: a data project, or a configuration?
Built as a data project: Bought as standardised fields from a data vendor, or keyed in by analysts.
Configured from what the firm has: Collected from public sources in the original language, every figure cited.
Built as a data project: Re-implemented as code in the system; changes need a release.
Configured from what the firm has: Loaded as versioned settings; changes need a second approver.
Built as a data project: Recomputed in a second engine that disagrees with the first.
Configured from what the firm has: Read daily from the risk engine the firm already runs.
Built as a data project: Edited in the new system and re-keyed into the limit system.
Configured from what the firm has: Written to the limit system only after a signed approval.
Built as a data project: A vendor demonstration on a large English-language bank.
Configured from what the firm has: A parallel run on the firm's own past reviews.
What is an approved counterparty list?
An approved counterparty list is the firm's register of the legal entities it may trade with, by product and by fund, each with its current rating, limit and next review date. For a UCITS fund it starts with a legal condition: counterparties to OTC derivatives must be prudentially supervised institutions of a category the fund's home regulator has approved (Directive 2009/65/EC, Art. 50(1)(g)(ii); the wording and the limits that follow are in UCITS counterparty limits).
The list has to be precise about entities, because limits, netting and reporting all attach to the legal entity that signed the agreement, not to the group. That precision is about to be tested for large hedge fund advisers. When the 2024 Form PF amendments apply on 1 July 2027 (91 FR 56593), they will identify their funds' significant counterparties "by legal name, LEI, and financial institution affiliation" (Form PF adopting release). A list keyed by trading name will not survive that report; one keyed by legal entity and identifier will.
What is a counterparty scorecard, and why bring your own?
A counterparty scorecard is the firm's method for turning a counterparty's figures into a rating: the drivers, the weights, the way each figure is scored and the mapping from score to notch. Bring your own, because the rating is the firm's judgement and has to match its risk appetite; Basel notes that a scorecard, used with guidance, can set how deep the due diligence goes for each level of counterparty risk (CRI40.11), which works only if the scorecard is the firm's.
In the sample, scorecard v4.2 has five drivers: capital 30%, liquidity 20%, asset quality 20%, profitability 15% and market signals 15%. It scores both the level of each figure and its one-year change, which is why a bank with a liquidity coverage ratio well above 100% can still lose a quarter of a notch on liquidity when the ratio falls sharply. A country ceiling caps the notch by jurisdiction. When the agents found the scorecard had no driver for deposit concentration, the gap went onto the list for the next version, a change that will need a second approver like any other.
The limit grid and approval rules: policy as settings
The limit grid and the approval rules are loaded as settings, versioned, with every change approved by a second person, so the policy in force on any date can be shown to an auditor. Basel asks that "authorship and ownership of policies and procedures should be clearly separated", and encourages banks "to aim for a yearly policy review" (CRI40.93).
The sample firm's counterparty policy, as the settings it was switched on with
| Setting | Sample value | What you set |
|---|---|---|
| Scorecard driver weights | Capital 30% · liquidity 20% · asset quality 20% · profitability 15% · market signals 15% | Your weights, totalling 100%, saved as a draft for approval |
| Confidence below which no rating is proposed | 0.85 | Your threshold; below it the analyst rates without a proposal |
| Agent disagreement that escalates | More than 1 notch | Your escalation rule |
| Watch trigger: capital fall in one month | 15% | Your trigger, with signals rated high, medium or low |
| Capital test | Banks: limit at most 2% of Tier 1 capital · broker-dealers: at most 10% of excess net capital | Your tests, beside the grid by notch and counterparty type |
| Approvals | Credit officer up to $50M · CRO co-signs above | Your delegation of authority; policy exceptions need a reason and the CRO |
| UCITS checks | Uncleared derivatives: 10% of assets per credit institution · 5% other · 20% combined | Checked fund by fund against fund administrator NAVs |
| Residency and retention | EU, US or Singapore hosting · seven years after the relationship ends | Your choice; legal hold on or off |
Roles and permissions: the delegation of authority, enforced
Exposure feeds and the systems a counterparty risk system must talk to
A counterparty risk system should read exposure from the risk engine and write signed decisions to the counterparty master and the limit system, and nothing else should flow the other way without a signature. The interagency guidance describes the monitoring the feeds must support: "Sufficiently automated monitoring processes to provide updated exposure measures at least daily", and controls such as "systems that assess a trade's impact on limit utilization prior to execution" (Interagency Supervisory Guidance).
What the system reads, what it writes, and when
| System | Reads | Writes | When it writes |
|---|---|---|---|
| Risk engine | Exposure and potential exposure by fund and product, intraday | Nothing | Never |
| Counterparty master | Legal entities, groups and LEIs | Signed ratings and review dates | After a signed approval |
| Limit system and order management | Current limits and utilisation | Signed limits, for pre-trade checks | After a signed approval |
| Market data and ratings feed | Bond spreads, CDS, equity prices, external rating actions | Nothing | Never |
| News and regulator notices | Local-language news and notices from 38 regulators | Nothing | Never |
How long does it take to load 400 counterparties?
Loading 400 counterparties is an import of the approved list and its identifiers; reviewing them is the long part, and the order matters more than the speed. No regulator or independent study publishes a typical load time, and it depends mostly on how clean the counterparty master is: duplicate entities, missing identifiers and group links that live in someone's head are what take time, not the software.
A sensible order for the first reviews is by risk, not alphabet: watchlist names first, then the largest exposures, then the oldest reviews, then reviews falling due. In the sample, the overnight run on the morning shown prepared 11 reviews and read 64 new filings, and the Spreading agent read nine annual reports in five languages into 1,656 cited lines. A pilot on a few dozen of the firm's own counterparties, including its hardest, is the honest way to measure throughput before committing to a date.
Once running: what the agents did overnight, and what needs a person
How long does a counterparty review take once it is running?
Once running, the analyst's part of an annual bank review is mostly checking flagged lines, judging the case and preparing it for approval. Botminds' estimate for one annual review is about 20 analyst hours by hand and about 3 with agents collecting, spreading and drafting; the design target is under four hours. Where those hours go, task by task, is set out in the counterparty credit analyst's week.
Approval time is a separate clock, and it is the firm's. In the sample, approvals carry a service level of two business days before escalating to the CRO, and limits above $50M wait for the CRO's co-signature after the credit officer has signed. The measures a risk committee should track once the system runs are in counterparty credit risk metrics.
Maker-checker above $50M: the credit officer's step signed, the CRO's to come
Counterparty risk system: questions to ask, and where this one fits
Ask any counterparty risk system vendor what it needs you to keep feeding it, who may change its rules, what it writes to your systems and when, and whether every figure opens its source. Then run it on your own past reviews. The answers separate systems that move the retyping from systems that remove it.
Counterparty Risk Management fits asset managers whose counterparty work is limited by reading: many banks and brokers, many languages, yearly reviews that crowd out monitoring. It brings agents that collect, spread, rate, challenge, size limits, watch and draft, and it leaves the rating, the limit and every exception with credit officers and the CRO. It does not calculate exposure, replace the limit system or onboard counterparties; legal entity set-up and trading documents stay with Counterparty Onboarding and the master agreements' terms with ISDA and CSA Data Extraction.
Questions people ask
What counterparty risk tools does an asset manager need?
At least four: a risk engine that measures exposure, a limit system that enforces limits before trades, a counterparty master that holds legal entities, and a review system that rates and limits each counterparty and keeps the audit trail. Monitoring between reviews can sit in the review system or beside it.
Can we keep our existing scorecard?
Yes, and you should. The scorecard is loaded as settings: drivers, weights, scoring and the notch scale. Changes are saved as a new version and need a second approver, so ratings made under the old version stay traceable to it.
Do we need a data vendor for bank financials?
Not for the reviews themselves, which read each counterparty's own filings. A market data and ratings feed is still useful for spreads, equity prices and rating actions between reviews, and a vendor's documents can be collected alongside public ones.
What happens to our past reviews?
A sample is used to test the agents against decisions the committee already made, and the rest stay as history. The first review of each counterparty in the new system compares against the last signed rating, so a notch change is visible from the start.
Where can the data be hosted?
In the sample settings the choices are the EU (Frankfurt), the US (Virginia) or Singapore, with retention of seven years after a relationship ends and a legal hold that can be switched on. Desks see only the counterparties they trade with.