Case Study 24.2: The Smart Contract That Didn't Know About the Regulatory Change

Background

Accord Derivatives Partners, a London-based derivatives broker with a specialized book in equity and rates products, had built its reputation on operational efficiency. Where other firms of similar size operated derivatives settlement through a combination of manual processes, bilateral confirmations, and spreadsheet-based reconciliation, Accord had invested heavily in automation. By 2023, the firm had achieved near-straight-through-processing for the majority of its flow product volume.

When the firm's technology team began exploring the use of smart contracts for initial margin calculation on bilateral OTC derivatives trades, the timing seemed propitious. The derivatives industry had spent years building common standards for margin calculation. The ISDA Standard Initial Margin Model (ISDA SIMM) provided a regulatory-accepted methodology for calculating initial margin on non-cleared OTC derivatives under the Uncleared Margin Rules (UMR), which required bilateral posting of initial margin between counterparties above specified threshold amounts. ISDA SIMM had achieved broad industry adoption and regulatory recognition across major jurisdictions.

The technology team proposed encoding the ISDA SIMM margin calculation in a smart contract deployed on a permissioned blockchain shared with Accord's major counterparties. When a bilateral trade was executed and confirmed, the smart contract would automatically calculate the required initial margin under ISDA SIMM, generate a margin call to the appropriate party, and record the calculation and call in an immutable audit trail. Human intervention would only be required in cases of genuine dispute about the inputs — the trade economics, market data, and so on — not in the calculation itself.

The compliance team reviewed the proposal and approved it, subject to a series of controls: the smart contract code must be independently reviewed before deployment; all inputs (trade data, market data) must come from validated, independently sourced feeds; the smart contract deployment must itself be a recorded, audited event; and any update to the contract code must go through the same review and approval process. The controls were documented, the code review was completed by a specialist external firm, and the smart contract was deployed in Q1 2024.

The Regulatory Change

ISDA SIMM is not static. ISDA publishes periodic updates to the model, calibrating risk weights and correlations to reflect observed market conditions, and incorporating feedback from regulatory consultations with CFTC, ESMA, and other supervisors. These updates — designated as new versions of the model (v2.2, v2.3, v2.4, v2.5, and so on) — require implementing firms to update their calculation systems within specified periods.

In April 2024, ISDA published ISDA SIMM v2.5, which included significant recalibrations to equity risk weights reflecting changed correlation structures observed in the post-pandemic market environment. The recalibration affected a material proportion of Accord's portfolio, particularly in its single-stock equity options book. Firms using ISDA SIMM were expected to implement v2.5 within a standard implementation window.

The recalibration memo was distributed across Accord's risk management function. The firm's internal risk models were updated. The documentation for the model governance committee was prepared. But the smart contract — which was in production, running on a permissioned blockchain shared with counterparties — was not updated. It continued calculating margin under the parameters of ISDA SIMM v2.4.

Nobody noticed immediately. The smart contract was running. Margin calls were being generated. The settlement process was operating. In the absence of a counterparty objection or an internal alert, there was no visible sign that anything was wrong.

The Discovery

The error was discovered six weeks after ISDA SIMM v2.5 became the expected calculation standard, during a routine model validation exercise conducted by Accord's model risk team. The model risk analyst, reviewing the automated margin calculations against a manual recalculation using ISDA SIMM v2.5 parameters, observed systematic differences in the equity risk weight outputs. The differences were not large on any individual trade — the largest discrepancy on a single position was approximately £340,000 — but they were consistent across the equity book, pointing to a parameter-level error rather than a data error.

The analyst escalated to the head of model risk, who escalated to the head of derivatives risk and to the compliance technology team. It took approximately two days of investigation to establish the root cause: the smart contract was running ISDA SIMM v2.4. The smart contract update — which required going through the approved change control process — had not been initiated because the person responsible for monitoring ISDA SIMM version updates had updated the internal risk models but had not identified the smart contract as a separate system that required a corresponding update.

The compliance team's initial assessment of the impact was uncomfortable reading. Over the six-week period, Accord had systematically under-collected initial margin from counterparties in positions where ISDA SIMM v2.5 produced a higher requirement than v2.4, and had systematically over-collected margin in positions where v2.5 produced a lower requirement. The aggregate net effect on any given counterparty depended on their portfolio composition, but for several major counterparties the margin discrepancy was material in absolute terms.

The "Code Is Law" Problem in Practice

The technical architecture of the smart contract compounded the problem in an important way. Because the margin call was generated by the smart contract, and because the smart contract's execution was recorded on the blockchain as an authoritative event, counterparties had relied on the smart contract's output as the correct margin call. Some had even configured their own systems to accept smart-contract-generated margin calls without secondary review, precisely because the smart contract was supposed to implement an agreed, audited methodology.

When Accord's compliance team began contacting counterparties to explain the error and propose reconciliation, several counterparties expressed a concern that went beyond the immediate financial adjustment: if the smart contract was authoritative, on what basis was Accord now claiming the smart contract's output was wrong? This was not a frivolous question. It touched directly on the "code is law" tension that smart contract deployments create: when a party has relied on the smart contract's output as the authoritative calculation, who bears the legal and financial consequences of a discrepancy between the code's output and the regulatory expectation?

The answer in this case was unambiguous from a regulatory perspective: Accord was the regulated entity. Accord was subject to the Uncleared Margin Rules. ISDA SIMM v2.5 was the applicable standard. The fact that Accord's smart contract had calculated using v2.4 did not change the regulatory requirement; it created a regulatory breach. The smart contract's output was not authoritative in any sense that overrode Accord's regulatory obligation. Accord was responsible for calculating margin correctly, and it had not.

The FCA was notified under Accord's breach reporting obligations. The notification described the root cause (failure to update the smart contract following an ISDA SIMM version change), the duration (six weeks), and the remediation plan (immediate smart contract update, margin reconciliation with all affected counterparties, and a process redesign to prevent recurrence). The FCA issued a supervisory letter requesting additional information about Accord's change management controls for smart-contract-based systems.

Redesigning the Smart Contract Architecture

The remediation exercise produced not just the immediate fix (a corrected smart contract, deployed through the emergency change control process) but a fundamental redesign of how Accord managed the smart contract going forward.

The core design flaw was the assumption that ISDA SIMM parameters could be embedded statically in smart contract code. ISDA SIMM is a living model that changes on a predictable but non-trivial schedule. Any smart contract implementation that hardcodes model parameters is a smart contract that will become incorrect every time the model is updated.

The redesigned architecture separated the stable elements of the contract (the calculation structure, the data ingestion process, the margin call generation logic) from the configurable parameters (the risk weights and correlations that are updated with each ISDA SIMM version). The parameters were stored in a separate on-chain data store that could be updated without redeploying the entire smart contract. Updating the ISDA SIMM parameters required approval from both Accord and the relevant counterparty (implemented through a multi-signature requirement), was recorded as an auditable event on the chain with the version number and effective date, and triggered a mandatory parallel-run period during which both the old and new parameters were used to calculate margin, with the outputs compared before the new parameters became live.

Critically, the ISDA SIMM update process — which had previously been managed purely within Accord's internal risk management framework — was now explicitly included in the smart contract change management register. The person responsible for implementing ISDA SIMM updates across all of Accord's systems had a checklist that included the smart contract parameter store as a required update target, alongside the internal risk models, the regulatory reporting system, and the client-facing documentation.

The redesigned system also incorporated a "circuit breaker" — a threshold comparison between the smart contract's margin calculation and an independent manual calculation run in parallel on a sample of trades. If the difference exceeded a specified tolerance, the smart contract would flag the discrepancy and require human review before generating the margin call. The circuit breaker was not a sign that the smart contract was unreliable; it was a recognition that a system of this consequence needed a systematic check that its automated logic remained aligned with the regulatory standard it was intended to implement.

Analysis

The Accord case is a textbook illustration of the gap between "the code is working" and "the code is compliant." These are two different questions. A smart contract can execute flawlessly — its logic running correctly, its outputs deterministic and reproducible — while simultaneously producing outputs that are non-compliant with applicable regulatory requirements, because the regulatory requirements changed and the code did not.

The compliance implication is not that smart contracts should be avoided in regulatory applications. It is that smart contracts in regulatory applications must be treated as regulatory systems, subject to the same change management discipline as any other compliance-critical infrastructure. Regulatory updates trigger a code review and update obligation, not just a documentation and internal model obligation.

More broadly, the case illustrates that the "immutability" of blockchain records creates a two-sided compliance posture. The immutable record of what the smart contract did is valuable evidence — it proves exactly what calculations were run, on what dates, with what inputs. In the Accord case, the immutable audit trail was part of what made the remediation efficient: there was no ambiguity about which trades had been affected, what margin had been called, and what the discrepancy was. But the same immutability means that the errors were preserved with perfect clarity. There was no ambiguity for the FCA, either.

Discussion Questions

1. The fundamental error in Accord's smart contract governance was the failure to include the smart contract in the ISDA SIMM update process. What organizational and process design changes would have prevented this? How should firms document the "regulatory update dependency" of each automated system in their compliance infrastructure?

2. The counterparties who had configured their systems to accept smart-contract-generated margin calls without secondary review suffered losses when the calculation was incorrect. To what extent, if any, do you think they bear responsibility for those losses? Does reliance on an automated system affect the legal analysis of responsibility for its outputs?

3. The redesigned architecture required both Accord and each counterparty to approve ISDA SIMM parameter updates (multi-signature requirement). What are the operational benefits and risks of this approach? Could multi-party approval create its own compliance problems — for example, if a counterparty refused to approve an update to current ISDA SIMM parameters?

4. Accord's compliance team notified the FCA of the breach. If you were drafting the FCA notification, what information would you include? What remediation commitments would be most likely to demonstrate to the FCA that the risk of recurrence had been addressed?

5. The "circuit breaker" mechanism compares smart contract outputs to an independent manual calculation on a sample basis. Design the specific parameters of this control: what sample size would you use, what tolerance would you set before flagging a discrepancy, and what would the process be for responding to a flagged discrepancy? Consider the trade-off between sensitivity (catching real errors) and specificity (avoiding false alarms that generate unnecessary operational friction).