What the tool intends to assess
Purpose, inputs, rules or method, expected outputs and intended users should be described clearly enough for a reviewer to challenge the result.

This register explains the intended purpose, publicly described data boundaries and evidence requirements of RegTech Nexus AI review-support tools. It is a transparency register—not an audit opinion, security certification, legal opinion or claim that every function has been independently tested.
Purpose, inputs, rules or method, expected outputs and intended users should be described clearly enough for a reviewer to challenge the result.
Representative workflows, boundary conditions, calculation examples, error handling, exports and browser behaviour require repeatable test evidence.
Processing, storage, network requests, browser storage, third-party services, retention and access statements should match observed implementation and documented controls.
These are initial profiles. They intentionally separate public product descriptions from claims that still require validation.
Trade-finance and transaction-risk review support using rule-based indicators.
Policy-to-control review signals and evidence-gap action planning.
Internal-control readiness, ownership and corrective-action planning.
A rule-transparent planning calculator based on user-selected official scale and phase assumptions.
Jurisdiction-oriented evidence-gap and action planning.
Banking-risk calculations mapped to standards and country rules.
| Control step | Minimum evidence | Review outcome |
|---|---|---|
| 1. Discover source | Issuer, jurisdiction, exact instrument, official URL and publication date. | Source is traceable to the primary issuer. |
| 2. Verify applicability | Relevant provision, scope conditions, effective date, amendments and supersession check. | Applicability is supported, qualified or marked for verification. |
| 3. Map requirement | Requirement-to-control mapping, assumptions and rationale. | Mapping is reviewable, not automatic legal interpretation. |
| 4. Test functionality | Test input, expected output, actual output, pass/fail, date and version. | Observed behaviour is distinguished from untested claims. |
| 5. Check data boundaries | Browser/network inspection, storage and export behaviour, third-party requests and disclosure review. | Data-handling claims match observed behaviour or are corrected. |
| 6. Approve and monitor | Reviewer, review date, issue log, next review trigger and change history. | Material changes can be traced and re-tested. |
Prefer official regulator or standards-body publications. Check the current instrument, amendment history, effective date and transition provisions. A source link alone does not establish applicability or correct implementation.