Keeping Up with Regulatory Change

The rules we operate under (AML, GDPR, the EU AI Act, sanctions lists, payment regulations) change, and "we built it to the old rules" is not a defence. Staying compliant is ongoing. We have to notice relevant changes, work out what they mean for the system, and implement them on time. Build so that change is expected, not a crisis.

Regulation keeps changing. Sanctions lists update constantly. AML expectations evolve. GDPR guidance shifts. The AI Act brings in new obligations in stages. Engineering rarely owns spotting the change (compliance does), but engineering owns implementing it correctly and on time, and building systems flexible enough to take in change without a rewrite.

The practical aims: keep values that change (thresholds, lists, rules) out of hard-coded logic where they are expected to change; treat regulatory deadlines as real commitments; and keep the evidence that shows we kept up (see Auditability & Evidence, Compliance by Design).

Build to absorb change

• DoKeep values that change by regulation (screening lists, thresholds, risk rules, retention periods) configurable and updatable, not buried in hard-coded logic (see Configuration).
• DoRefresh external regulatory data (sanctions/PEP lists) on the right schedule, and re-apply it (for example, re-screening) rather than checking only once (see AML Screening).
• DoWork closely with compliance to turn a regulatory change into concrete, tested requirements, and treat its deadline as a real commitment.
• ConsiderDesigning rules and decisions so they can be versioned, so you can show which rules applied to a past decision (see Audit Trails).
• AvoidHard-coding regulatory values (thresholds, country lists, retention periods) as magic numbers scattered through the code. They will change, and you will miss some.

Implement and evidence it

• DoImplement regulatory changes on time and verify them with tests, especially safety-critical ones (fail-closed, screening) (see Testing Strategy).
• DoKeep evidence of the change (what changed, when it took effect, and that it was applied) for audits (see Auditability & Evidence, Marketplace & Certification Readiness).
• DoRe-check existing data and decisions where a change requires it (for example, re-screen against an updated list, or apply a new retention rule).
• NeverKnowingly run past a regulatory deadline, or ignore a known change that applies to us, without escalating it. "We didn't get to it" is not a defence (see Professional Ethics).

Self-review checklist

• AskAre the regulation-driven values here configurable, or hard-coded where a change would be missed?
• AskDoes external regulatory data (lists) refresh and re-apply on the right schedule?
• AskIs a known regulatory change being implemented on time and tested?
• AskCan we evidence what rules applied, and when they changed?