Approving a Rules Engine for Regulatory Capital Calculation

Apache-2.0 obligations are manageable but not zero: retain the NOTICE file and attributions in distributions, do not use the project's marks to endorse the bank's product, and note that the patent grant terminates if the bank sues anyone over the software. Record the licence in the SBOM and in the component inventory.

The AGPL library is the real finding. AGPL's distinguishing obligation triggers on interaction over a network: users interacting remotely with a modified version must be offered its corresponding source. Two questions decide the exposure:

• Is the module actually in the dependency graph? Optional modules frequently get pulled in by a default profile or a transitive dependency. Resolve the graph with the reporting module disabled and see whether the AGPL library is still present. If it is, the "optional" label is wrong and this is a mandatory finding.
• Is the reporting module network-reachable? Even if the rules engine itself is internal, a reporting service that renders PDFs to users is likely to be. The safe assumption in a regulated bank is that anything reachable from a service UI is network-interactive.

Do not accept AGPL in the calculation path. Replace the PDF library with a permissively licensed alternative, or isolate the reporting function behind a separately deployed service boundary after legal sign-off. Isolation is a mitigation, not an exemption - get it documented, because the next reviewer will ask the same question.

The CVE is a blocker regardless of licence. A critical CVE in a pinned dependency with no fixed release means the bank must patch it itself or upgrade off the pinned branch. Approving on the basis that "it's only parsing JSON" is not defensible in a regulatory calculation.

Accountability stays with the bank. Adopting open source transfers maintenance effort, not responsibility. The model owner named in the model inventory is accountable for the calculation; the component is registered as a third-party dependency with its own risk rating. "The community maintains it" is not a control.

Quantify the exposure first: one dominant maintainer is a bus factor of one; nine months without a commit and a stale release is an active signal, not a theoretical one; and the commercial edition creates a structural incentive for the vendor to keep some capability proprietary - check now whether the bank needs any feature that only exists there, because that changes the whole business case.

Exit plan contents:

• Pinned version and digest, with source archived in the bank's artefact repository so the code cannot be lost if the repository disappears.
• A reproducible build demonstrated from source, including toolchain and dependency resolution, run at least once before go-live. An exit plan you have never executed is a wish.
• Demonstrated patch capability: the bank has applied one security patch to a private fork and shipped it, and knows how long that takes.
• Named owning team and budget for carrying the fork, with at least two engineers who understand the codebase.
• Revisit triggers written into the risk record: no release in 12 months, a critical CVE unfixed after 90 days, the maintainer changing employer or licence, the vendor discontinuing the commercial edition.
• A migration path to at least one alternative engine, with an estimate of effort.

Alternative to fork: a support contract with the commercial vendor converts the risk into a contractual relationship - but read what it actually covers: patching SLAs, indemnity, and whether the bank gets fixes to the open source edition or only to the proprietary one.

Validation has to cover two distinct things: the engine as software, and the rules the bank writes in it. The engine is a tool, not the model - but a tool that silently mis-evaluates a rule is a model failure with a vendor's name on it.

Requirements I would set:

• Engine-level validation: an independent test suite of rules with known expected outputs, including edge cases around numeric precision, date handling and rule ordering. Financial calculations fail on rounding and precedence far more often than on logic.
• Version and provenance control: the exact version, commit and artefact hash recorded in the model inventory, with the SBOM, and a change-control step that requires re-validation on any upgrade. No automatic minor-version upgrades in production.
• Documented behaviour at boundaries: what the engine does with nulls, type coercion and conflicting rules; where the bank relies on behaviour that is not specified upstream, record it as an assumption with a test that would fail if upstream changed it.
• Independent review of the rule set by someone who did not write it, plus a sample of settlements or capital outputs recomputed by an alternative method.
• Ongoing monitoring: reconciliation of outputs across periods, and a defined tolerance for drift.

Document the dependency itself in the model documentation: why this engine, what the alternatives were, the licence review outcome, the exit plan, and the residual risk accepted. That record is what an examiner reads, and it is what turns "we use an open source library" into a defensible decision.