One supplier. Every regulatory view, up to date.
The same cloud provider is an ICT third-party under DORA, an outsourcing arrangement under banking rules, a data processor under GDPR, and often an item on two or three other registers. Most compliance teams hold these as separate spreadsheets that drift out of sync the moment a contract changes. On this platform the supplier exists once. Every regulatory view is a live read of that one record.
One supplier, one contract, classified per framework.
A supplier on this platform is a single record: legal name, the identifiers a supervisor recognises (LEI, EUID, VAT), where it is headquartered, who ultimately owns it, and what you spend with it each year. A contract is a single record that points at that supplier: who signed it, which entity it serves, what it costs, when you can exit, and which country your data lives in.
What makes the module regulatory, rather than an address book, is the classification layer. For each framework that applies to your firm (DORA, the EBA outsourcing guidelines, Solvency II, MiCAR, others) a supplier carries a named judgement: critical, material, or not material, with the person who made the call, when they made it, and when it is due to be reviewed. The same supplier can be DORA-critical and EBA-material at the same time. Moving from one framework to another is a change of view, not a parallel spreadsheet.
Suppliers come in pre-populated. The hyperscalers, core-banking platforms, and application providers common in EU financial services are already in the catalogue with their identifiers filled.
The supplier is one object. The frameworks are views of it.
On the typical stack, each regulatory framework is its own register. The outsourcing register is a workbook. The DORA Register of Information is a separate workbook. The records of processing under GDPR live with the DPO. When a supplier is replaced, all three update separately, by different people, on different cadences. Reconciliation is the weekly tax the compliance team pays.
On this platform the supplier exists once. The DORA view reads that record and renders it in the shape the regulator expects. The outsourcing view reads the same record and renders it in the shape the banking guidelines expect. The GDPR view reads the same record and renders the processing information. When the supplier is amended once, every view is current.
The specific claim is not that the platform preconfigures every framework a supplier can appear in. It is that the object every framework asks about (this supplier, this contract, this service) is managed once. The regulatory views are generated, not re-entered.
Most tools duplicate. This platform references.
The common alternative is per-framework duplication. A general compliance tool holds "outsourcing arrangements" as one list, "ICT third parties" as another, "data processors" as a third. The same vendor appears three times with three records. When the legal name changes, three records change, if anyone remembers. When one gets updated and the others drift, the drift is invisible until a supervisor asks a pointed question.
On this platform every reference points back to one supplier record. The contract references the supplier. The function that depends on the service references the supplier through the contract. The GDPR processing record references the supplier. There is no duplication, so there is no drift. If you restructure the group, the ownership chain updates once and every view reflects it.
Contracts work the same way. A master agreement is a record; work orders under it are records that reference the master. Amend the master once and the context of every work order is current.
Strong today. Named boundaries.
This is the strongest module on the platform today. You can populate the supplier landscape on day one from the EU supplier library, classify per framework, and read the DORA view immediately. Contracts, services, and their assessments are all in product.
What the module does not yet produce as a finished document is a submission-ready outsourcing register for the banking or insurance supervisor. The platform holds every data point these registers ask for, but the formatted export templates are being built. Our specialists produce those artefacts from the platform data in the meantime.
Customer-side anti-money-laundering is not this module's job. It has its own: the AML and KYC module carries customer due diligence and ownership look-through. The incident module now records and manages ICT incidents; the structured incident-to-supplier link is still being wired, so incident-linked views of a supplier remain on the roadmap.
A discovery call, not a product demo.
You describe the compliance problem consuming the most of your team's time. We walk the platform through an example close enough to your operation that you can judge whether this way of modelling compliance fits how you want to work.
Book a discovery call →