Establish the operating perimeter
List the regulated entities, products, customer types, assets, networks, origin and destination jurisdictions, and counterparties that the configuration must support. Do not begin with a single threshold field before the perimeter is understood.
Map requirements to controls
For each corridor, record the requirement source, effective date, interpretation owner, threshold treatment, data requirements, counterparty conditions, and evidence retained.
| Decision | Configuration object |
|---|---|
| Is information exchange required? | Applicability and threshold rule |
| Which party data is required? | Required and conditional fields |
| Can the counterparty receive it? | Capability and protocol profile |
| What if information is unavailable? | Hold, review, reject, or fallback route |
| What proves the rule was applied? | Configuration and transaction evidence |
Test the configuration
Include tests at, above, and below each threshold; missing fields; contradictory jurisdiction data; unsupported counterparties; unhosted wallets; duplicate requests; delayed acknowledgements; and configuration version changes.
Expected outcomes should be approved before test execution. A test that only records what the system happened to do does not prove the intended control.
Approve and publish
The approval package should include:
- Requirement and interpretation references.
- Configuration export and version.
- Test cases, expected outcomes, and actual results.
- Known limitations and manual controls.
- Effective date and rollback owner.
- Impacted corridors, systems, and counterparties.
Monitor change
Trigger reassessment when regulations, regulator guidance, entity scope, products, corridors, counterparties, protocols, or internal risk policy change. Use the knowledge graph to identify which documents, controls, and configurations depend on the changed entity.