Periodic refresh

Overview

Regulators expect the information you hold on a customer to stay accurate for as long as the relationship lasts, and expect you to re-verify it on a cadence that reflects the risk the customer represents.

Periodic refresh in Ondorse turns that obligation into a continuous, automated process. Ondorse computes an expiry date for every case from your own refresh policy, watches the portfolio for cases that reach it, and gives your team a workflow to re-verify and re-decide those cases — without anyone having to maintain a spreadsheet of review dates.

How it works

Refresh policy

Your Refresh policy defines the cadence:

Ondorse ships with a risk-based refresh policy:

  • Low risk: every 5 years
  • Medium risk: every 3 years
  • High risk: every year

Customise: these are defaults, not constraints. You can shorten or lengthen each period, add tiers, or drive the period from other case data — entity type, jurisdiction, product, or a custom field.

Refresh date

Each case carries an refresh date derived from its last refresh date and the refresh policy that applies to it.


Reactivity: if anything that feeds the policy changes — most often the case's risk level — the refresh period and expiry date are recomputed automatically. A case whose risk is upgraded mid-relationship can therefore become due for refresh immediately, rather than waiting out a cadence set under its old profile.

Automatic report of cases to refresh

A dedicated scan runs continuously across your entire case base and reports every case whose verification has expired.


Notice period: you can configure how far in advance you want to be warned, so cases appear ahead of their expiry date and your team has room to collect documents and complete a review before the deadline passes.

Anticipate: in Dashboard you can get a view on refresh volume to come:

Refresh process

Starting a refresh re-opens the case and puts it back through verification: the configured verification workflow tasks re-run, registry and third-party sources are re-queried, new persons are screened if necessary, documents are re-checked for validity, etc..


You can also use Portal to collect data from the customer.

Refresh decision: the case stays in a state requiring action until an analyst records a new decision. That decision sets a new last-refresh date, from which the next expiry is computed, and the cycle starts again.


Why it matters

  • Continuous coverage: every case is monitored against your policy from the day it is decided, with no manual tracking and no cases quietly falling out of scope.
  • Risk-proportionate effort: review cycles follow the risk the customer actually presents, so analyst time concentrates where it counts.
  • Policy you control: the cadence is configuration, not a product assumption. When your policy changes, the portfolio realigns to it automatically.
  • Audit-ready by construction: expiry dates, refresh history, and the decision recorded at each cycle are captured on the case, so you can evidence to a regulator or auditor that periodic review is genuinely operating.
  • A closed loop: detection, outreach, re-verification, and decision live in one system, which is what keeps a periodic review programme from stalling between the report and the remediation.

Did this page help you?