Abstract
Distributed financial systems are usually designed around individual operations.
A payment succeeds or fails. A deposit settles or reverses. A withdrawal is confirmed. A guarantee covers a loss. A reserve absorbs an exposure.
Real systemic failures rarely respect those boundaries.
Multiple transactions may depend on the same settlement provider, correspondent bank, custodian, blockchain bridge, stablecoin issuer, jurisdiction, liquidity facility, or operational control plane. A single upstream disruption can therefore invalidate thousands of apparently independent operations at once.
The resulting problem is not merely correlated transaction failure.
It is economic contagion.
A reversal can create obligations. Those obligations consume guarantees. Guarantees consume reserves. Reserve depletion changes availability policy. Reduced availability creates liquidity pressure. Liquidity pressure may force asset sales or delay settlement. Those actions create new dependencies and expose additional participants.
What began as a failure in one domain becomes a propagation process across an economic graph.
This article develops a model for reasoning about that propagation. We examine correlated failure domains, exposure graphs, capacity-bounded absorption, guarantee exhaustion, endogenous contagion, hidden dependencies, observability limits, stress propagation, and the difference between conserving nominal value and containing economic loss.
The important question is no longer whether a transaction can fail.
It is whether the system knows how far that failure is allowed to travel.
Transaction-level reasoning breaks at correlated failure
Suppose a platform processes 20,000 deposits.
Each deposit is worth 100 units.
Every individual transaction is small.
The risk engine may therefore conclude that each exposure is harmless:
transaction exposure = 100
guarantee capacity = 1,000,000
100 << 1,000,000
At the transaction level, the system looks extremely safe.
Now suppose all 20,000 deposits clear through the same settlement provider.
The relevant comparison is no longer:
100 versus 1,000,000
It is:
20,000 * 100 = 2,000,000
2,000,000 versus 1,000,000
The guarantee that looked enormous at transaction scale is insufficient at failure-domain scale.
Nothing about the individual transactions changed.
What changed was the question.
Local risk asks:
Can this transaction be absorbed?
Systemic risk asks:
Which transactions can fail together?
That second question is where contagion begins.
Independence is an architectural assumption
Many risk calculations implicitly assume independence.
If transaction reversals are individually unlikely, then large simultaneous losses appear extremely unlikely.
For independent events:
P(A and B) = P(A) * P(B)
If:
P(A) = 0.001
P(B) = 0.001
then:
P(A and B) = 0.000001
That looks comforting.
Unfortunately, financial infrastructure is full of common causes.
If A and B both depend on the same provider, then:
P(A and B | provider failure)
may be close to one.
The risk was never two independent reversals.
It was one shared dependency with two downstream consequences.
This distinction is critical because transaction-level data often makes correlated exposures look diversified.
Ten thousand transactions may involve ten thousand customers while still depending on one bank.
A million blockchain transfers may involve millions of addresses while depending on one bridge contract.
Five custody providers may appear separate while operating under the same legal freeze.
Diversity of transaction identity is not diversity of failure domain.
Exposure graphs
A useful model represents the system as an exposure graph.
Nodes represent economic or operational entities.
Edges represent dependencies through which loss, unavailability, or liability can propagate.
A simple graph might contain:
Customer Deposits
|
v
Settlement Provider
|
v
Platform Guarantee
|
v
Customer Available Balance
|
v
External Withdrawals
A more realistic system contains several layers:
Bank A --------\
\
Bank B ----------> Settlement Layer
|
Bank C ----------/
|
v
Platform Ledger
|
+-------+-------+
| |
v v
Trading Withdrawals
| |
v v
Collateral Blockchain
|
v
Credit
The graph is not merely about data flow.
It represents economic dependence.
If Bank A fails, which positions depend on its settlement?
If collateral becomes invalid, which credit obligations become undersecured?
If a bridge is paused, which customer balances remain nominally correct but operationally unusable?
The graph answers questions that service topology cannot.
Microservice architecture tells you who calls whom.
Exposure architecture tells you who loses what when something upstream stops being true.
Financial edges carry more than value
A dependency edge should not only contain an amount.
It may need:
amount
asset
finality_state
reversal_class
liability_holder
guarantee_reference
collateral_reference
failure_domain
recovery_priority
For example:
ExposureEdge:
source: deposit_bucket_42
destination: guarantee_G
amount: 4,200,000 USD
finality: provisional
failure_domain: settlement_provider_A
reversal_class: provider_return
The same economic amount may participate in several risk relationships.
A 1 million deposit may be:
1 million settlement exposure
1 million customer liability
600k guaranteed exposure
400k reserved exposure
Those numbers do not necessarily represent different money.
They represent different claims over the same underlying event.
That distinction is essential when calculating contagion.
Propagation is conditional
Exposure does not automatically propagate through every edge.
A guarantee may absorb loss.
Collateral may cover an obligation.
A reserve may prevent downstream balances from becoming negative.
A settlement delay may create liquidity pressure without creating nominal loss.
The graph therefore needs transition rules.
Conceptually:
loss_out =
max(
0,
loss_in
- absorption_capacity
)
If a node receives 500,000 of loss and has 700,000 of available capacity:
loss_out = 0
The contagion stops.
If it receives 1,200,000:
loss_out = 500,000
The node absorbs part of the shock and propagates the remainder.
This is why guarantees are better modeled as capacity-bounded absorption nodes than magical finality boundaries.
Capacity is stateful
A common mistake is treating guarantee capacity as a static property.
Suppose a guarantee has:
capacity = 1,000,000
After absorbing a loss of 300,000:
remaining capacity = 700,000
The risk profile of every other transaction depending on the same guarantee has changed.
No transaction needs to fail for this to matter.
A previous loss altered the system’s ability to survive the next one.
This is endogenous state.
The effective exposure of a transaction therefore depends on current global capacity, not only on its own attributes.
A simplified model is:
C_(t+1) = C_t - absorbed_loss_t + replenishment_t
Future safety depends on:
remaining_capacity_t
not the capacity declared when the guarantee was created.
Capacity claims need evidence
Even the value of C is not automatically factual.
A guarantee may claim capacity of 10 million.
That capacity may be backed by:
posted collateral
cash reserves
a credit facility
an insurance contract
a parent-company commitment
an internal self-report
These are not economically equivalent.
The system should distinguish nominal capacity from effective capacity.
For example:
GuaranteeCapacityClaim:
guarantor
nominal_capacity
asset
asserted_at
evidence_type
evidence_reference
encumbrance
expiry
policy_digest
The risk engine then derives:
effective_capacity =
capacity_policy(
nominal_capacity,
collateral_quality,
evidence_freshness,
encumbrance,
enforceability,
liquidity
)
The result must preserve both inputs and policy identity.
Otherwise:
effective_capacity = 8,000,000
becomes another unexplained number on a dashboard.
Derived risk state requires provenance too.
The absorbing node can fail
Suppose a platform guarantee absorbs provisional settlement exposure.
Operationally:
provisional deposit
-> guarantee
-> clean customer balance
Downstream systems no longer need to track the deposit directly.
This is useful compression.
But the guarantee has finite capacity.
Once:
aggregate_draw > effective_capacity
the abstraction breaks.
Previously clean downstream value is now exposed to the guarantee’s inability to absorb further loss.
This does not necessarily mean historical customer balances should suddenly be relabeled provisional.
The economic meaning has changed in a different way.
The platform has become undercapitalized relative to the obligations it guaranteed.
This creates second-order exposure.
The original risk was:
settlement provider may fail
The new risk is:
platform may fail to honor the guarantee
A failure crossed a trust boundary and created a new failure domain.
That is contagion.
First-order and second-order contagion
It is useful to distinguish propagation levels.
First-order contagion comes directly from the original shock.
Example:
Bank A failure
-> 5M deposits reverse
Second-order contagion comes from the system’s response to first-order loss.
For example:
5M reversals
-> guarantee loses 5M
-> liquidity reserve depleted
-> withdrawal limits reduced
Third-order effects may follow:
withdrawal restrictions
-> customers move balances elsewhere
-> further liquidity outflow
At this point the system is no longer reacting only to the original bank failure.
It is reacting to the consequences of its own defensive behavior.
This is endogenous contagion.
A failure can propagate without accounting loss
Contagion is not limited to balance-sheet losses.
Suppose a blockchain bridge becomes unavailable.
No funds have necessarily disappeared.
But assets on one side of the bridge can no longer be moved to the network where obligations must settle.
The system has:
nominal assets
but lacks:
usable settlement liquidity
This can create:
delayed withdrawals
failed arbitrage
collateral shortfalls
margin pressure
emergency rebalancing
The contagion mechanism is liquidity rather than direct loss.
Similarly, a bank API outage may prevent reconciliation.
Without fresh evidence, the platform may reduce provisional availability.
That can reduce customer liquidity even though every underlying transaction eventually settles correctly.
The shock propagated through uncertainty.
Exposure and liquidity are different graphs
A robust architecture may need separate but connected graphs.
The exposure graph answers:
Who loses value if this source fails?
The liquidity graph answers:
Who loses the ability to settle obligations if this source becomes unavailable?
An asset may have low loss risk but high liquidity criticality.
For example:
Custodian A:
extremely safe assets
but primary source of same-day settlement liquidity
If Custodian A becomes unavailable, the platform may remain solvent but operationally unable to pay.
Solvency and liquidity are different properties.
Distributed financial systems need to model both.
Correlated failure domains
The obvious failure domains are usually known:
settlement provider
bank
custodian
blockchain
bridge
stablecoin issuer
cloud region
jurisdiction
The dangerous dependencies are often hidden.
Two settlement providers may clear through the same correspondent.
Two custodians may depend on the same infrastructure provider.
Three supposedly independent chains may use the same bridge.
Several banks may share the same regulatory exposure.
The real graph therefore contains dependencies that the platform does not know.
This means the declared exposure graph is incomplete by construction.
It is not the world.
It is the organization’s current hypothesis about the world.
Declared domains are priors
A declared failure domain should therefore be treated as prior knowledge.
For example:
Source A:
declared_provider: Provider X
Source B:
declared_provider: Provider Y
The model may initially assume independence.
Later, empirical behavior may show correlated failures.
Perhaps both providers repeatedly experience disruption simultaneously.
The system then has evidence that the declared dependency graph is missing something.
It may not know whether the hidden domain is:
a correspondent bank
shared infrastructure
jurisdiction
liquidity provider
network dependency
The important fact is that the independence assumption has weakened.
Correlation hypotheses
Rather than forcing every dependency to be known, the risk model can maintain hypotheses.
CorrelationHypothesis:
source_set
declared_domain
evidence_reference
estimated_dependence
confidence
observability
first_observed_at
last_observed_at
This allows the architecture to represent:
known shared dependency
suspected shared dependency
observed co-movement without known cause
insufficient evidence
Those are meaningfully different states.
Observed is not the same as observable
This becomes especially important in low-volume parts of the system.
Suppose two counterparties have almost no reversals.
The system sees no correlation.
That could mean:
they are independent
or:
there was not enough failure data to detect dependence
The absence of observed co-movement is not evidence of independence unless the observation process had enough power to detect meaningful co-movement.
A correlation observation should therefore preserve its detection boundary.
For example:
CorrelationObservation:
source_set
observation_count
reversal_count
observed_co_movement
minimum_detectable_co_movement
significance_threshold
observation_window
Then:
observed correlation = 0
minimum detectable correlation = 0.40
means almost nothing.
While:
observed correlation = 0
minimum detectable correlation = 0.02
is useful negative evidence.
This distinction should reach dashboards.
Otherwise, the quietest and least understood dependencies produce the cleanest-looking metrics.
Unknown dependency risk
Because the graph is incomplete, the system should never present:
largest_correlated_failure_exposure
as an absolute truth.
At best it knows:
largest_modeled_correlated_failure_exposure
That is a lower bound over the modeled domains.
There may be larger hidden correlated shocks.
A useful risk output may therefore include:
largest_declared_correlated_exposure
detection_coverage
minimum_detectable_dependency_strength
unmodeled_dependency_alerts
The goal is not to calculate one impressive number.
It is to show what the number actually knows.
Concentration is structural
Transaction concentration is often measured by amount.
For example:
Provider A: 35%
Provider B: 30%
Provider C: 20%
Provider D: 15%
This may look diversified.
But if A, B, and C clear through the same upstream institution, the actual concentration is:
Shared Domain Z: 85%
Concentration therefore exists at every layer of dependency.
The system should evaluate concentration over:
direct providers
upstream providers
custodians
issuers
rails
legal entities
jurisdictions
technical infrastructure
liquidity sources
Where dependency information is incomplete, the model should state that explicitly.
Contagion through customer behavior
Not all propagation is encoded in transaction graphs.
Customer behavior can create feedback.
Suppose a provider outage causes withdrawal delays.
Customers observe delays and begin withdrawing more aggressively.
The system experiences increased outflow.
That outflow consumes remaining liquidity.
Reduced liquidity causes stricter withdrawal limits.
Those restrictions produce additional customer concern.
The feedback loop is:
provider outage
-> delayed withdrawals
-> customer concern
-> increased withdrawal demand
-> liquidity depletion
-> tighter controls
-> more concern
This is endogenous behavioral contagion.
Nothing about the initial transaction architecture alone captures it.
A platform managing systemic exposure needs operational policies that account for feedback, not only static balance relationships.
Contagion through collateral
Suppose provisional funds are used to purchase an asset.
That asset becomes collateral.
The collateral backs credit.
The original settlement reverses.
Now the platform may liquidate the asset to recover the missing value.
If the asset price falls simultaneously, collateral becomes insufficient.
The chain is:
provisional deposit
-> asset purchase
-> collateral
-> credit
A reversal at the source can therefore affect credit exposure several operations later.
If many customers follow the same path, forced liquidation may move the market price.
Then:
forced liquidation
-> market price declines
-> other collateral positions weaken
-> more liquidations
The contagion has crossed from settlement risk into market risk.
This is precisely why transaction-level risk categories become insufficient in interconnected systems.
Risk transforms as it propagates.
Risk transformation
An exposure edge should therefore not merely copy risk.
Operations transform it.
Conceptually:
R_out =
T(
R_in,
operation,
market_state,
collateral_state,
liquidity_state
)
Settlement risk can become:
credit risk
liquidity risk
market risk
counterparty risk
operational risk
A graph node may absorb one class while creating another.
For example, a platform guarantee removes settlement uncertainty from the customer but converts it into platform credit exposure.
The system has not eliminated risk.
It has changed its owner and form.
Systemic safety requires bounded propagation
A well-designed system does not need to prevent every failure.
That is impossible.
It needs to prevent failures from propagating without bounds.
Useful boundaries include:
reserves
collateral
position limits
counterparty limits
withdrawal limits
guarantee capacity
circuit breakers
settlement segmentation
asset segregation
liquidity buffers
These are containment mechanisms.
Their purpose is not only to reduce expected loss.
They reduce graph connectivity under stress.
Segmentation
One powerful containment strategy is segmentation.
Instead of sharing one guarantee across every channel:
Global Guarantee
-> Bank
-> Card
-> Stablecoin
-> Bridge
the platform may allocate separate capacity:
Guarantee_Bank
Guarantee_Card
Guarantee_Stablecoin
Guarantee_Bridge
A failure in one domain cannot consume every reserve.
This sacrifices some capital efficiency.
That tradeoff is deliberate.
Shared pools maximize normal utilization.
Segmentation improves failure isolation.
The same tension appears throughout distributed systems.
Efficiency prefers shared resources.
Resilience prefers boundaries.
Capacity partitioning
Capacity may also be dynamically partitioned.
Suppose:
total reserve = 10M
The platform may allocate:
Bank settlement: 4M
Card reversal: 2M
Blockchain: 2M
Bridge exposure: 1M
Unallocated emergency buffer: 1M
These allocations can change with current exposure.
But automatic reallocation must obey limits.
If every domain can consume the entire reserve during stress, the apparent partitions provide no real containment.
The architecture needs hard or policy-enforced boundaries.
Contagion-aware availability
Availability decisions should consider systemic exposure, not only transaction risk.
A customer deposit may be individually safe but arrive through an already concentrated provider.
The system may therefore reduce early availability.
Conceptually:
availability =
f(
transaction_risk,
customer_risk,
source_finality,
failure_domain_concentration,
guarantee_headroom,
liquidity_state
)
This creates an important property.
As concentration increases, the platform automatically becomes more conservative.
Risk controls respond before the correlated failure occurs.
Guarantee headroom
A useful quantity is:
guarantee_headroom =
effective_capacity
- current_absorbed_loss
- modeled_pending_exposure
But again, modeled pending exposure is only as good as the dependency graph.
A safer interpretation might distinguish:
declared_headroom
stress_headroom
declared_headroom uses the known graph.
stress_headroom applies correlated failure scenarios.
A guarantee may have positive declared headroom while failing almost every meaningful stress scenario.
That is a very different risk state.
Stress propagation
Static exposure metrics cannot reveal every nonlinear failure.
A better approach is to simulate shocks.
For each scenario:
1. select failed source set
2. invalidate affected exposures
3. propagate losses
4. consume guarantee capacity
5. consume reserves
6. recalculate liquidity
7. trigger policy responses
8. propagate second-order effects
The result may contain:
initial_loss
absorbed_loss
unabsorbed_loss
liquidity_shortfall
affected_customers
guarantees_exhausted
reserves_breached
dependent_operations_at_risk
This is closer to distributed fault injection than traditional reporting.
The system asks:
What happens if this assumption becomes false?
Stress scenarios should include hidden-domain hypotheses
Known failure domains are the obvious scenarios.
The system should also test synthetic correlations.
For example:
top two settlement providers fail together
all custodians in jurisdiction J freeze
all bridges for asset X become unavailable
stablecoin X becomes illiquid
largest liquidity provider disappears
These scenarios may not correspond to known shared dependencies.
That is the point.
Stress testing should challenge the graph model, not merely replay the dependencies already encoded in it.
Graph cuts
A useful way to reason about systemic resilience is through cuts in the exposure graph.
Suppose a source region can propagate loss to customer balances only through Guarantee G.
Then G forms a cut.
If G has sufficient capacity:
upstream shock <= G
the downstream region remains isolated.
If:
upstream shock > G
the cut fails.
The safety of the downstream graph therefore depends on:
cut_capacity >= plausible_correlated_shock
This is more meaningful than simply saying the guarantee covers individual transactions.
The relevant question is whether the cut can absorb the failure set expected to reach it.
Multiple cuts
Real systems may have several layers:
provider exposure
-> provider reserve
-> platform guarantee
-> emergency capital
-> customer loss
Each node absorbs part of the shock.
The system survives while cumulative absorption is sufficient.
If:
L = original loss
C1 = provider reserve
C2 = platform guarantee
C3 = emergency capital
then final unabsorbed loss is:
max(0, L - C1 - C2 - C3)
But only if capacities are actually independent.
If C1 and C2 depend on the same frozen bank account, summing them is false.
Capacity itself has a dependency graph.
Humans, having discovered recursive complexity, naturally decided to build financial infrastructure on top of it.
Capacity correlation
Two guarantees may appear independent while depending on the same collateral.
For example:
Guarantee A:
backed by Treasury Account X
Guarantee B:
backed by Treasury Account X
Nominally:
A capacity = 5M
B capacity = 5M
The platform may incorrectly infer:
total capacity = 10M
But if Account X contains only 5M:
joint realizable capacity = 5M
Capacity claims therefore need lineage too.
The system must know what assets or commitments back each guarantee.
Otherwise the same collateral can be counted several times.
Capacity lineage
A guarantee may be backed by:
cash
securities
credit line
insurance
future receivables
Each backing source has its own failure domains.
For example:
Guarantee G
|
+--> Cash at Bank A
+--> Credit Line from Bank B
+--> Government Bonds at Custodian C
If Bank A and Bank B share a liquidity shock, effective guarantee capacity may collapse faster than nominal accounting suggests.
The guarantee is not merely an absorbing node.
It has its own upstream graph.
Recursive exposure graphs
At sufficient scale, there is no clean distinction between protection and exposure.
A guarantee protecting one graph is itself backed by another graph.
Collateral protecting a credit position depends on markets and custody.
Insurance depends on insurer solvency.
Liquidity facilities depend on counterparties.
Every safety mechanism eventually rests on another assumption.
The architecture should therefore aim not for assumption-free safety, but for explicit assumption boundaries.
Failure-domain invariants
Certain structural properties can be checked continuously.
For example:
single_domain_exposure <= domain_limit
guaranteed_exposure <= effective_guarantee_capacity
shared_collateral_claims <= realizable_collateral
external_withdrawable_provisional_value
<= available_liquidity_buffer
largest_modeled_correlated_shock
<= aggregate_independent_absorption_capacity
The word independent is critical.
Summing correlated capacities creates fictional resilience.
Loss conservation
Contagion modeling also needs a conservation property.
A loss cannot disappear merely because it crosses a boundary.
For a propagation node:
incoming_loss =
absorbed_loss
+ propagated_loss
+ recovered_loss
If:
incoming_loss = 1M
absorbed_loss = 400k
recovered_loss = 100k
then:
propagated_loss = 500k
Any model producing:
incoming_loss > absorbed + recovered + propagated
has lost exposure information.
This is analogous to value conservation in a ledger.
It is risk conservation.
Distribution matters as much as totals
Conservation alone is insufficient.
Two systems may both have:
total exposure = 10M
System A:
100 independent domains * 100k
System B:
1 domain * 10M
The totals are identical.
The systemic risk is not.
Risk models therefore need both:
exposure magnitude
exposure topology
This is why simple aggregate limits cannot replace the graph.
Causal provenance during contagion
When a shock propagates, the system should preserve why each downstream restriction or loss occurred.
For example:
provider_failure_A
-> guarantee_draw_991
-> reserve_threshold_breach
-> withdrawal_policy_reduction
An operator should later be able to explain:
Why was Customer X limited?
Not merely:
risk system decided so
but:
because Provider A failed,
which consumed 82% of Guarantee G,
which reduced available liquidity below policy threshold L,
which activated withdrawal policy P.
This is decision provenance applied to systemic behavior.
Observability under contagion
A platform should monitor more than nominal exposure.
Useful metrics include:
largest modeled correlated exposure
largest unabsorbed stress loss
guarantee headroom
guarantee capacity utilization
liquidity buffer utilization
exposure concentration by domain
exposure concentration by suspected domain
shared collateral ratio
correlation detection coverage
number of unresolved correlation hypotheses
largest capacity shortfall under stress
The most dangerous metric may be:
unmodeled_dependency_surface
Not because it can be measured precisely, but because the organization should know how much of the graph lacks meaningful dependency evidence.
Safe uncertainty
A mature system does not pretend uncertainty has disappeared.
It preserves:
known dependency
suspected dependency
insufficient evidence
unknown dependency
and adjusts policy accordingly.
Low-observability domains may receive stricter exposure limits.
New counterparties may begin with conservative capacity.
Guarantees backed by weak evidence may receive discounted effective capacity.
Risk policy compensates for epistemic uncertainty.
Architecture
A contagion-aware risk subsystem may look conceptually like:
Ledger Events
Settlement Events
Reversal Events
Liquidity State
Guarantee State
Correlation Evidence
|
v
Dependency Graph
|
v
Exposure Projection
|
+----> Concentration Analysis
|
+----> Guarantee Capacity Model
|
+----> Stress Propagation Engine
|
+----> Availability Policy
|
+----> Treasury Controls
|
+----> Operational Alerts
The dependency graph should be reconstructible from durable evidence.
Stress results should include policy and input provenance.
No derived risk number should exist without the system being able to explain how it was produced.
Formalizing propagation
A simplified graph can be represented as:
G = (V, E)
where each node v has:
capacity C(v)
and each edge e carries:
exposure X(e)
A shock originates at source set:
S subset V
For each affected node, propagated loss may be approximated as:
P(v) =
max(
0,
sum(incoming losses)
- C(v)
)
This is only a starting model.
Real systems may have:
priority rules
partial recoveries
time-dependent capacity
asset conversion
legal seniority
collateral haircuts
liquidity constraints
But even a simplified explicit propagation model is better than treating every exposure independently.
Time matters
Contagion unfolds over time.
A guarantee may have sufficient capital but insufficient immediate liquidity.
A credit line may become available several hours later.
Collateral may require liquidation.
Insurance recovery may take months.
Therefore capacity should include temporal availability.
Instead of:
capacity = 10M
the system may need:
capacity:
immediate: 2M
within_1h: 4M
within_1d: 8M
eventual: 10M
A platform facing 6M of withdrawals in ten minutes does not have 10M of operational capacity.
It has 2M.
Timing converts solvency into liquidity risk.
Contagion is path-dependent
The order of shocks can change the result.
Suppose Guarantee G has 5M capacity.
Two domains each expose 4M.
If Domain A fails first:
G absorbs 4M
remaining capacity = 1M
Domain B then fails:
3M propagates
If both shocks occur simultaneously, policy may allocate capacity differently.
Perhaps proportionally:
2.5M absorbed from A
2.5M absorbed from B
The same total exposure creates different downstream obligations depending on allocation policy.
Contagion simulation must therefore preserve event ordering and capacity allocation rules.
Allocation under capacity exhaustion
When capacity is insufficient, the system needs an explicit allocation policy.
Possible rules include:
FIFO
proportional
priority by customer class
priority by legal seniority
priority by settlement channel
priority by collateralization
manual intervention
This is not a technical detail.
It decides who absorbs loss.
Therefore the exhaustion policy must be:
versioned
auditable
reproducible
legally reviewed
operationally observable
A guarantee without an exhaustion policy is only complete while it is never exhausted.
Which is an impressively convenient assumption.
Circuit breakers
Containment may require stopping propagation before certainty is available.
If correlated failures suddenly appear, the system may:
reduce provisional availability
pause withdrawals from affected sources
increase reserves
disable certain settlement routes
require additional confirmation
stop accepting new exposure
These are financial circuit breakers.
They should trigger on economic state, not merely technical error rates.
For example:
if guarantee_headroom < threshold:
reduce early availability
if correlated_failure_exposure > domain_limit:
stop new exposure
if liquidity_buffer < critical_level:
restrict irreversible outflows
Each trigger should produce provenance.
Recovery
Recovery from contagion is not merely restarting services.
The system must unwind economic state.
That may involve:
replenishing guarantees
collecting obligations
releasing reserves
reconciling affected transactions
reassigning liabilities
restoring withdrawal capacity
closing correlation hypotheses
updating failure-domain models
The recovery process should shrink the exposure graph deliberately.
Otherwise old incident state continues influencing future risk decisions indefinitely.
Learning from contagion
Every correlated incident reveals information about the dependency graph.
A mature system should update its model.
If two providers fail together repeatedly, the correlation hypothesis strengthens.
If a guarantee performs exactly as expected during stress, its evidence quality improves.
If a supposed independent reserve becomes unavailable alongside the exposure it was meant to cover, the model has discovered a dangerous shared dependency.
Incidents therefore produce architectural evidence.
The system should not only recover from them.
It should learn topology from them.
Conclusion
Distributed financial failures become systemic when exposure propagates faster than the architecture can contain it.
Transaction-level correctness is not enough.
A system may process every individual operation correctly while accumulating catastrophic correlated exposure through shared settlement providers, liquidity sources, custodians, bridges, jurisdictions, guarantees, or collateral.
A resilient architecture models economic dependencies explicitly.
It distinguishes transaction diversity from failure-domain diversity, treats guarantees as finite absorption nodes, preserves evidence behind capacity claims, tracks uncertainty in correlation assumptions, and stress-tests how losses move through the graph when assumptions fail.
Most importantly, it recognizes that risk does not disappear when ownership changes.
It changes form.
Settlement risk can become credit risk.
Credit risk can become liquidity risk.
Liquidity pressure can become market risk.
Market losses can weaken collateral.
Weak collateral can create more credit loss.
At that point, the system is no longer processing isolated transactions.
It is managing a dynamic network of economic dependencies.
The relevant safety property is therefore not:
every transaction can fail safely
It is:
no plausible failure can propagate beyond the capacity
of the boundaries designed to contain it
That is the difference between handling failure and engineering against contagion.
Top comments (0)