Central bank collateral eligibility rule testing

Central bank collateral eligibility rule testing checks whether a system correctly applies a central bank's published or internally configured criteria to determine whether an asset can be accepted as collateral. It verifies the decision against the applicable policy version, asset data and assessment date, including outcomes for eligible, ineligible and unresolved cases. The criteria and results depend on the relevant central bank and facility.

What the testing covers

Eligibility rules may assess instrument type, issuer, currency, credit quality, marketability, legal status or other policy-defined attributes. The precise criteria vary by framework, so test expectations should come from an approved rule specification and its effective dates. A test should identify the central bank or facility, the policy version, the asset and the date of assessment.

Testing checks that the application interprets each criterion correctly and combines conditions in the intended way. It also checks how the system handles data dependencies, such as issuer classifications or credit assessments. Incorrect mappings, stale reference data, inconsistent date handling and rule-precedence defects can produce a wrong decision even when individual conditions appear correct.

Eligibility is distinct from collateral valuation and haircuts. Eligibility determines whether an asset meets acceptance criteria. Valuation establishes its recognised value, while a haircut adjusts that value under applicable rules. These processes may share data or run in the same platform, so integration tests should verify their hand-offs while keeping expected outcomes distinct.

How to test the rules

Translate each policy condition into testable statements and map them to expected outcomes. Decision table testing for banking rules can help cover combinations of criteria, including cases where one failed condition makes an asset ineligible. Include boundary cases such as an assessment immediately before and after a rule's effective date, where the specification defines a change.

Use controlled test data with known values and provenance. Include valid records, boundary values, missing attributes, conflicting reference data and records with dates that exercise policy changes. Preserve relationships between asset, issuer and rating records. Banking test data management is relevant when test datasets need repeatable setup and refresh controls.

A practical example is a rule requiring an accepted instrument type, an approved currency and a qualifying credit assessment. Create one asset that meets all three conditions, then vary one condition at a time. The expected result is eligible when all required conditions pass and ineligible when a required condition fails. For a missing or stale credit assessment, assert the specified outcome, such as unresolved or referred for review, rather than assuming the system should treat it as a pass or fail.

Tests should also verify the decision record: the result, assessment date, policy version and reasons for the outcome. Where the system exposes reason codes, check that they identify the failed or unresolved condition. This makes defects easier to diagnose and supports review of rule changes.

Common failure modes and verification

Failures can arise when a rule uses the wrong policy version, an asset attribute is mapped to the wrong source field, or an update reaches one application before another. Date and time handling can also select the wrong rule around an effective-date boundary. In automated tests, unstable or uncontrolled reference data can make results hard to reproduce.

Verify outcomes at the rule service or system interface that makes the decision, then check relevant downstream use in the Collateral management system testing workflow. For a rule change, run regression tests against both affected cases and representative unchanged cases. Confirm that test evidence records the input data, policy version and expected and actual results.