Sheepdog Prosperity Partners
Due Diligence

Time Series in Foundry: Modeling Counterparty Risk Trajectories and Early-Warning Indicator Pipelines

by | May 15, 2026 | DD Tech Lab | 0 comments

What you’ll be able to do after reading this. Recognize the difference between a single-point risk rating and a risk trajectory, and what the latter adds for portfolio-level monitoring. Read a composite-scoring formula with weighted component signals and translate it to the practitioner’s “what is the model actually saying” intuition. Recognize the SR 11-7 / OCC 2011-12 model-governance expectations that apply to any composite-scoring deployment and the validation framework the institution must execute. Identify threshold-engineering failure modes (alert fatigue, particularly) and the calibration discipline that prevents them. Document the model-validation lineage in workpapers that survive SR 11-7 §V documentation review and ongoing-monitoring expectations.

Terms anchored before the article walks them, with the math bridges the article uses throughout.

  • Composite score — a single number derived from multiple component signals via a weighted sum. The composite this article walks is $\text{composite} = 0.40 \cdot \text{sanctions} + 0.25 \cdot \text{media} + 0.20 \cdot \text{transaction} + 0.15 \cdot \text{kyc}$, where each component is a number between 0 and 1 and weights sum to 1.0. The weights are illustrative; production weights require institutional elicitation.
  • Exponential decay — a mathematical pattern where a quantity diminishes at a rate proportional to its current value, producing the characteristic curve where “old things matter less than new things, in a smooth way.” The sanctions signal uses $\text{decay} = e^{-\ln(2) \cdot d / 90}$, where $d$ is days-since-the-hit and 90 is the half-life. At $d=0$ (just happened), decay = 1.0; at $d=90$ (half-life), decay = 0.5; at $d=270$ (three half-lives), decay ≈ 0.125.
  • Rolling window — an aggregation over the most recent N days, sliding forward each day. The 90-day adverse-media count is $\sum_{i=0}^{89} \text{mentions on day}(t-i)$ — the count of mentions in the trailing 90 days as of date $t$.
  • z-score — a standardized measure of how far a value sits from a baseline mean, in units of the baseline’s standard deviation. $z = \frac{x – \mu}{\sigma}$ where $x$ is today’s value, $\mu$ is the 30-day rolling mean, $\sigma$ is the 30-day rolling standard deviation. A z-score of 3 means today is three standard deviations above the trailing-month average.
  • CUSUM (Cumulative Sum) — a sequential change-detection method from Page (1954). The practitioner reads it as “the running sum of recent deviations from baseline, with an alarm threshold.” Useful for spotting regime changes earlier than absolute-threshold rules.
  • GARCH (Generalized Autoregressive Conditional Heteroskedasticity) — a class of statistical models that capture persistent volatility in time series. The Stochastic / Markov sub-series the Quiver for Ad-Hoc Counterparty Queries article (Stochastic Volatility Models for Restatement-Timing Anomalies) covers GARCH; this article references it as the rigorous alternative to the z-score heuristic.
  • SR 11-7 — Federal Reserve Supervisory Guidance on Model Risk Management, jointly issued with OCC Bulletin 2011-12 in April 2011. §IV covers governance and segregation of duties; §V covers documentation, ongoing monitoring, and periodic re-validation. The composite-scoring pipeline is a “model” under this framework’s definition.

A counterparty’s risk profile is rarely a single point. It is a trajectory — improving as KYC refreshes complete and adverse-media coverage settles, deteriorating as sanctions exposure builds, fluctuating with macroeconomic conditions that affect entire jurisdictions or sectors. The single-point risk-rating the Counterparty ontology object holds at any given moment (the topic of the forthcoming Counterparty Ontology Design article) is the current value of an underlying time series. For portfolio-level risk officers responsible for thousands or tens of thousands of counterparties, the trajectory is the more operationally useful analytical object than the current value.

This article walks the time-series modeling patterns for counterparty risk. How to define a TimeSeries object tied to each Counterparty. How to engineer the component signals — sanctions exposure, adverse-media density, transaction anomaly, KYC freshness — that combine into a composite risk score. How to translate trajectory changes into threshold-based alerting that hands off to the Actions framework (Foundry Actions Framework) for analyst escalation. How to feed the time series back to the Workshop application (Workshop Application Patterns) as the trajectory visualization investigators expect to see. And — load-bearing per the SR 11-7 / OCC 2011-12 documentation expectations that every part of this article ultimately operates under — the model-risk governance discipline the institution must execute on top of the platform’s primitives.

The composite scoring framework is genuinely useful for portfolio-level monitoring. The validation discipline that makes it deployable in a regulated context is what distinguishes a defensible early-warning indicator from a regulatory liability. The article addresses both.

Trajectory versus snapshot

The Counterparty.risk_rating field at any given moment is a single value. The institution’s ratings classification — typically a five-to-eight-letter taxonomy from “low” through “critical” — collapses a counterparty’s risk picture into a single ordinal level. The current value answers the question “where does this counterparty stand right now”; it does not answer the question “how did it get there” or “where is it going.”

Portfolio-level risk officers ask the second class of question constantly. A counterparty that has held risk_rating=”high” for eighteen months continuously is operationally different from a counterparty that crossed into “high” two weeks ago after sustained deterioration through “medium” over the prior quarter. The current rating is the same for both; the trajectories are very different, and the operationally appropriate institutional response is very different. A counterparty whose composite risk-score trajectory is improving may warrant the inverse action: not escalation, but reduced surveillance frequency.

The platform-side answer is a TimeSeries ontology object tied to each Counterparty. The time series carries the trajectory at appropriate temporal resolution — typically daily, though weekly is sometimes sufficient for portfolios where the underlying signals move slowly. The composite score at each time point is computed from a small set of component signals derived from the underlying ontology objects (sanctions hits, adverse-media mentions, transactions, KYC events). The time series is the analytical object portfolio officers and investigators query, visualize, and reason from.

Foundry time-series primitives

Foundry’s TimeSeries object class is a structured representation of a sequence of (timestamp, value) pairs with metadata about the source, the frequency, the units, and the linkage back to the parent ontology object. The platform indexes time-series objects for efficient time-window queries; a query for “all counterparty composite scores in the last ninety days” runs in seconds rather than minutes against a portfolio of hundreds of thousands of counterparties.

The time-aligned join pattern is the operationally important one. The composite score depends on four component signals, each derived from different underlying source data (sanctions effective dates, mention dates, transaction dates, KYC refresh dates). Each component signal is itself a time series. Composing the composite score requires joining the four series on aligned time points — for each counterparty and each date in the lookback window, pull the four component values and combine them. The platform’s time-series engine handles this pattern natively; the engineering work is the signal construction, not the join orchestration.

The companion bundle’s transforms/counterparty_risk_trajectory.py ships the full PySpark transform implementing the pattern. The transform builds a daily date spine over the 730-day lookback, computes each component signal independently against the underlying ontology objects, and combines the four into the composite score with three audit-metadata columns (pipeline_run_id, transform_version, computed_at) on every output row.

Component-signal engineering

The four signals the worked example combines are illustrative — institutions with different ontology compositions will have different signal sets, and the same institution will refine signal choices over time as it learns which signals predict which outcomes. The point of walking the four canonical signals is to demonstrate the engineering discipline that produces audit-defensible component construction; the specific choices are starting points, not recommendations.

Sanctions exposure signal. A counterparty with an active sanctions hit on the current date registers at 1.0. The signal decays with a 90-day half-life — an old hit eventually washes out of the composite, while a recent hit dominates. The functional form is exponential: decay = exp(-ln(2) * days_since_hit / 90). The institutional rationale for the half-life is the typical regulator expectation that recent sanctions exposure carries more weight than historical exposure; a counterparty with a 2018 sanctions hit who has been in good standing since carries less risk-weight than a counterparty with a 2026 hit, even if the historical exposure is theoretically observable in both cases. The 90-day half-life is institution-tunable; some institutions use 180-day or 365-day half-lives depending on their risk tolerance.

Adverse-media density signal. The 90-day rolling count of adverse-media mentions for a counterparty, log-scaled and saturated at 1.0. The construction is media_signal = min(log1p(mention_count_90d) / 5.0, 1.0). The log scaling prevents a single high-volume news event — fifty articles about an industry-wide event that mention the counterparty as one of many — from dominating the signal relative to a more concerning pattern of five mentions across distinct matters. The 5.0 denominator and the saturation at 1.0 are calibration choices; the institution’s quantitative team should validate these against labeled outcomes before deployment.

Transaction-anomaly signal. The absolute z-score of daily transaction volume against a 30-day rolling-window baseline (excluding the current day). The construction is transaction_signal = min(|daily_volume - rolling_mean| / rolling_std / 5.0, 1.0) when the rolling standard deviation is positive. The pattern is a standard anomaly-detection primitive used in transaction monitoring across the industry; the institution should treat the specific window size and the saturation calibration as starting points subject to their own validation against false-positive tolerance.

KYC freshness signal. Zero immediately after KYC refresh, ramping to 1.0 at 540 days (eighteen months) stale, saturating at 1.0 beyond. The construction is kyc_signal = min(max(days_since_kyc / 540, 0), 1). KYC freshness is a process-quality signal more than a risk signal — the institution’s KYC refresh cadence is a policy choice, and the signal value captures how aligned the counterparty’s KYC record is with the institution’s policy at the current date. The 540-day reference point corresponds to typical institutional cadence policies (annual to 18-month).

The companion bundle’s feature_schema/risk_trajectory_features.yaml captures each signal’s canonical definition, source data, mathematical construction, audit-defensibility note, and illustrative weight in the composite. The schema is the institutional reference for what each signal is and how it was derived — the document the model-validation team reads first when assessing the composite for SR 11-7 §V.A documentation sufficiency.

Composite scoring

The composite risk score combines the four component signals with weights summing to 1.0. The worked example uses illustrative weights of 0.40 sanctions, 0.25 media, 0.20 transaction, 0.15 KYC. These weights are starting points, not recommendations.

The weight-elicitation problem is harder than the implementation. The institution that picks weights at the engineering team’s discretion is doing model risk management wrong. Weights should emerge from a structured elicitation process involving risk-officer leadership, compliance-side review, and validation against historical outcomes. The institution that has weights without an elicitation record cannot defend the weights when an examiner asks how they were chosen.

The alternative composite functions the seed mentions — the Beneish-M-style relative composite and the Dechow-F-style discrete-flag composite — illustrate two genuinely different framings. The Beneish M-score (Beneish 1999) frames each component as a deviation from peer median rather than an absolute level; this is useful for institutional portfolios where absolute risk levels are less meaningful than relative ranking. The Dechow F-score (Dechow et al. 2011) frames components as discrete flags (above-threshold yes/no) summed to a discrete score rather than a continuous weighted sum; this trades resolution for interpretability. The institution’s choice among the three framings is itself a model-design decision that warrants explicit treatment in the model-validation documentation.

The composite formula is mechanically simple — a linear combination with bounded inputs. The institutional discipline that surrounds it is what regulators care about. Documented derivation. Quantitative validation against labeled holdout outcomes. Sensitivity analysis on weight perturbations. Periodic re-validation under the institution’s model-risk policy. Without those, the composite is just a number with no defensible interpretation. With them, the composite becomes a useful early-warning indicator the institution can rely on.

Threshold engineering and the alert-fatigue problem

The composite score becomes operationally useful when threshold-based alerting translates trajectory changes into analyst escalations. The companion bundle ships four alerting rules in threshold_alerting/threshold_to_action_handoff.yaml, each mapping a specific trajectory pattern to a specific Foundry Actions Framework action handoff.

The first rule fires when the composite score crosses 0.60 (the “high” threshold) on a given day where the prior day was below 0.60. The action handoff is EscalateToEDD — the counterparty routes to senior-analyst review with the composite score time series, the top contributing component signal, and the linked underlying ontology objects pre-populated. The threshold value is illustrative.

The second rule fires when the composite crosses 0.85 (the “critical” threshold). The action handoff is ElevateRiskRating with new_risk_rating=critical, and per Foundry Actions Framework‘s dual-approval pattern, the action requires compliance-manager approval. The threshold value is illustrative.

The third rule fires when the composite’s daily change relative to a 30-day rolling baseline exceeds three standard deviations. This is a rapid-deterioration signal — change-point detection in the spirit of Page (1954) cumulative-sum tests, though using a simpler z-score heuristic for operational ease. The action handoff is EscalateToEDD with an emphasis on investigating the triggering event in the change-point window. The threshold value is illustrative.

The fourth rule is the queue-staleness failsafe. When a counterparty’s composite has held above 0.60 for fourteen consecutive days without any analyst action (no EscalateToEDD or ElevateRiskRating recorded in the window), the system notifies the senior-analyst team distribution list. The rule catches the failure mode where the initial alert was missed or queued but not acted on. Fourteen days is the operational tolerance; institutional policy may tune.

The unifying concern across all four rules is alert fatigue. An alerting system that produces too many alerts gets ignored — analysts develop heuristic dismissal patterns, the alert volume exceeds the analytical capacity to triage, and the system’s correctly-identified true positives get lost in the noise. The companion bundle’s alert-fatigue calibration checklist describes the operational discipline: measure alert volume at proposed thresholds against 90-day historical data before deployment; compute precision (fraction of alerts producing actions) and adjust thresholds; target alert volume that consumes under twenty percent of analyst time on review-queue triage. Skipping the calibration is the deployment failure mode that turns a useful early-warning system into background noise within six weeks.

Model-risk governance — the load-bearing section

The composite-risk-score model produced by the trajectory pipeline falls squarely within the definition of “model” under SR 11-7 and OCC Bulletin 2011-12: it applies statistical, economic, financial, and mathematical theories, techniques, and assumptions to process input data into quantitative estimates. The platform does not change this. The Foundry runtime executes the model; the regulatory expectations around the model attach to the institution regardless of which platform executes it.

The companion bundle’s model_governance/sr_11_7_validation_framework.md walks the validation framework in detail. The summary worth flagging here is that the framework is not optional. Composite scoring with documented weights, threshold-based alerting, and change-point detection are exactly the kinds of decisions the regulators wrote the model-risk-management framework to govern, and deploying the pipeline without the validation work is a deferred regulatory consequence rather than an avoided one.

The institution must, at minimum, before deploying the model: register the model in the institutional model inventory; assign an owner; assign a validator independent of the developer (per SR 11-7 §IV segregation of duties); tier the model by inherent risk (composite scoring driving regulatory rating actions is typically Tier 1 or Tier 2). The institution must, as part of pre-deployment validation: confirm conceptual soundness of each component signal and the composite weighting; perform holdout backtesting on labeled outcomes; run sensitivity analyses on weights (varying each ±50%, confirming rank-ordering stability) and on thresholds (varying ±0.10, confirming alert volume operational tractability); compute precision and recall on the production thresholds against labeled outcomes; document everything with the specificity SR 11-7 §V.A.4 expects.

The institution must, ongoing: verify pipeline-run completeness monthly; compute precision/recall on the trailing quarter’s actuals; benchmark against any challenger model the institution maintains. The institution must, periodically: re-validate fully on the Tier 1 annual cadence (or Tier 2 every 2-3 years). The institution must, on every model change: have the validator review the change rationale, re-validate on the same labeled holdout, document, and approve through the institutional model-risk committee.

Every threshold value, every weight, and every decision rule shipped in the companion bundle is flagged as illustrative only. The institution must substitute its own calibrated values during deployment, and the version-controlled commit substituting them is itself a model-change event under the governance framework. The discipline is not optional.

The framing the article holds throughout is the same framing Articles 005 and 010 hold: the platform provides the primitives; the institution provides the discipline. Either alone is insufficient. The platform-side runtime executes the model the institution validates; the institution-side validation makes the model defensible regardless of which platform executes it.

Early-warning indicator patterns and bridges to the Stochastic sub-series

The threshold rules in this article use simple z-score heuristics for change-point detection. More rigorous methods exist and are the topic of DD Tech Lab’s Stochastic / Markov sub-series. CUSUM (cumulative-sum) tests per Page (1954) detect distributional shifts in sequential data with bounded false-positive rates; the companion bundle for Stochastic the Foundry Actions Framework for Audit-Trail Discipline article covers the operational implementation. Bayesian change-point models per Adams and MacKay (2007) provide posterior distributions over change-point timing rather than point estimates; the Stochastic the Time Series in Foundry: Modeling Counterparty Risk Trajectories article covers stochastic-volatility frameworks like GARCH (Engle 1982, Bollerslev 1986) that capture persistent volatility regimes. Higher-order and variable-order Markov models (Stochastic the Foundry Ontology Design for Beneficial-Ownership Networks article) catch long-memory fraud schemes where the simple z-score rule fails.

The reader graduating from this article to the Stochastic sub-series gets a more rigorous methodological foundation for the threshold engineering that this article presents in heuristic form. For institutions operating at scales where the heuristic false-positive rate is operationally tolerable, the heuristic is sufficient. For institutions with portfolios large enough that even small false-positive-rate improvements translate to material analyst-time savings, graduating to the rigorous methods is the right operational move.

Workshop integration and the analyst surface

The trajectory feeds back to the Workshop application (Workshop Application Patterns) as the visualization investigators expect. The investigator who opens counterparty CP-SYNTH-00007’s card sees the composite-risk-score time series rendered as a line chart in the contextual navigator. The line crosses the 0.40 threshold visibly on day 285 of the 365-day window — the AlertEntry timestamp shows the same date. The component-signal contributions panel shows what is driving the current score: sanctions signal at 0.95 contributing 0.380 of the composite, transaction signal at 0.40 contributing 0.080, media and KYC at baseline. The investigator can drill into the underlying ontology events in the change-point window — the specific sanctions hit that started the ramp, the specific transactions that pushed the secondary signal — without leaving the Workshop card.

The pattern of “composite at the surface, components on hover, underlying events on click” is the same information-density gradient Workshop Application Patterns walks. The trajectory is the unit at the top of the card; the components are the dependent detail one click away; the comprehensive event log is two clicks away. The investigator’s path through the visualization follows the analytical flow: see the trajectory, ask what drove it, ask what specifically happened.

Worked example

The companion bundle’s tools/generate_synthetic_trajectories.py produces a deterministic 50-counterparty × 365-day synthetic time series with two injected deterioration patterns. CP-SYN-007 (gradual_sanctions_buildup) shows a sanctions signal ramping from 0 to 0.95 over days 180-365, with secondary transaction-anomaly ramping in parallel; the composite crosses 0.40 on day 285. CP-SYN-023 (episodic_media_spike) shows a 30-day adverse-media surge starting day 250, with co-spiking transaction anomaly; the composite crosses 0.60 on day 255 and peaks above 0.85.

The trajectory pipeline runs daily at 04:00 institutional time. On day 286, CP-SYN-007’s threshold rule fires: composite crosses 0.40 (composite_crosses_high in the rule taxonomy). The AlertEntry generates with primary driver identified as sanctions_signal at 0.95. The senior-analyst review queue receives the alert. The analyst reviews the trajectory, drills into the change-point window, sees the specific sanctions-hit event from day 180 and the parallel transaction-volume ramp, and submits an EscalateToEDD action per Foundry Actions Framework‘s discipline. The EDDEngagement ontology object created by the action is linked to the counterparty; the AuditEntry captures the analyst’s lineage, justification, and supporting evidence (which includes the AlertEntry itself, closing the audit chain from trajectory through alert through action through AuditEntry).

On day 256, CP-SYN-023’s threshold rule fires: composite crosses 0.60 (composite_crosses_critical). The dual-approval pathway activates per Foundry Actions Framework. The senior analyst submits ElevateRiskRating with new_risk_rating=critical; the compliance manager approves; the resulting AuditEntry captures both users and both roles. The post-execution hook routes the case to the regulatory-filing review queue with one-business-day SLA.

The full audit chain — composite-risk-score time series, AlertEntry, EscalateToEDD or ElevateRiskRating AuditEntry — survives all the way to examiner-readiness eighteen months later. The examiner who asks “show me the surveillance trail for CP-SYN-007” gets the time series, the alert, and the action documented as a connected sequence. This is the operational success state. The platform provides the primitives that make it possible; the institution’s model-risk governance discipline, threshold-calibration validation, and analyst training make it defensible.

A grounding case: when early-warning model failures appear in enforcement

The institutional history of bank enforcement includes recurrent patterns where early-warning indicator systems either did not exist or did not produce timely alerts. The TD Bank BSA program failures (FinCEN Consent Order 2024, $1.3B penalty, DOJ guilty plea same month) cited multi-year transaction-monitoring deficiencies — exactly the workflow class an early-warning trajectory model is designed to support. The Capital One AML enforcement (OCC Consent Order 2020) similarly cited monitoring environment limitations.

The composite-scoring pattern this article walks is a platform-side mechanism for closing the operational gap that produces these findings. The mechanism is not novel — composite risk scoring is a 1990s-era discipline at the underlying technique level — but its scale and the institutional model-governance discipline required to deploy it defensibly are what distinguish a regulator-defensible early-warning system from background noise.

What the practitioner does with this reference. When designing or evaluating an early-warning indicator program, ground the design in the regulator’s documentation expectations under SR 11-7 §V. The model-governance framework (companion bundle model_governance/sr_11_7_validation_framework.md) is non-optional; the platform-side runtime executes the model, but the institution-side validation is what makes the model defensible. Workpaper documentation should include: the model inventory entry, the pre-deployment validation report with conceptual-soundness, quantitative testing, and outcomes-based testing sections, the ongoing-monitoring quarterly results, and the change log capturing every model parameter change with validator review and approval chain.

Authority

Companion repository

The Time Series in Foundry: Modeling Counterparty Risk Trajectories article’s full companion bundle lives at github.com/noahrgreen/dd-tech-lab-companion/articles/008_time_series_counterparty_risk_trajectories/. It ships the PySpark trajectory transform, the feature schema for the four component signals, the threshold-to-Action handoff rules, the eight-section SR 11-7 / OCC 2011-12 model-risk-governance validation framework, the deterministic synthetic-data generator producing the 50-counterparty × 365-day worked example, and the screenshot-equivalents showing the TimeSeries Viewer with component breakdown, the AlertEntry triage card, the Workshop drill-down view, and the Pipeline Builder DAG. Beneficial-Ownership Networks takes the ontology layer one level deeper into beneficial-ownership-network modeling — the substrate that several of this article’s signals ultimately depend on.

Submit a Comment

Your email address will not be published. Required fields are marked *