Use Cases
You verified them at onboarding. That was six months ago.
Between onboarding and today, companies change directors. Change IBANs. Change names. Dissolve. Get acquired. None of that is visible in your ERP. All of it is in the government registry. sikker.me never stops watching.
The gap fraud exploits
The structural assumption every fraud exploits.
Standard vendor verification stores a record at onboarding and assumes it stays accurate. It does not. In a five-year vendor relationship, a company may:
1–3×
Director changes
1–2×
Registered address updates
0–2×
Bank account changes
1×
Ownership event — acquisition, merger, MBO
Every one of these changes is filed in the public registry. None of them automatically update your vendor master. Fraud exploits this gap. sikker.me closes it.
How it works
Event-driven. Not scheduled. Not manual.
sikker.me maintains a continuously updated knowledge graph of every entity in your vendor list. Registry events trigger graph updates in real time. Updates are compared against the last verified state. Structural deviations fire an alert. You do not need to request a re-verification. You do not need to run a periodic audit. The graph watches. You get an alert when something changes.
Events monitored
Specific events. Named sources. Timestamped.
Regulatory requirement
Continuous monitoring is not just good practice. It is the law from July 2027.
AMLR Regulation 2024/1624 (applies July 10, 2027) requires obliged entities — including factoring and invoice financing companies — to maintain ongoing CDD records with documented update cycles:
High-risk
Refresh every 12 months maximum
All others
Refresh every 5 years maximum
Event-triggered
Whenever circumstances change
Static onboarding records do not satisfy this requirement. sikker.me's continuous monitoring architecture generates the update cycle documentation Article 26 requires — automatically, for every vendor in your list.