About
Most financial entities already knew which vendors mattered. What changed in January 2025 is that they have to prove it continuously: a Register of Information that matches reality, contracts that carry the provisions Article 30 names, assessments that vendors actually complete, evidence that has not quietly expired, and a management body that can be shown to have been informed.
Relynt exists because that work does not fit in a spreadsheet, and because the platforms that do handle it were built for institutions with a department to run them.
Why we exist
Almost every team we have spoken to started the same way. A workbook for providers, a second for contracts, a shared mailbox for vendor responses, a folder of certificates with names like final_v3_signed. It works until the first supervisory question, which is never “show me the file” but “where did this value come from, who changed it, and when”.
The deeper problem is that a register maintained by hand is a snapshot of a moment that has already passed. Procurement signs something, architecture moves a workload, a certificate expires, and the file is quietly wrong in three places. Rebuilding it every reporting cycle is the tax people pay for not having the records underneath.
The other half of the problem is proportionality. A forty-person payment institution has the same regulatory obligations as a large bank and perhaps one person to meet them. The tools built for the bank assume a programme team, a six-month implementation and a budget with a comma in it. That gap is the one we set out to close.
How we decide
These are not values on a wall. Each one has cost us a feature or a price point.
Teams that submit cleanly stopped maintaining a register file and started maintaining the records underneath it: providers, services, contracts, functions, subcontractors. Everything in Relynt is built that way round. The Register is generated from live records, so it cannot drift from what the business actually runs on, and every value can be traced to the record it came from.
Model-assisted review reads a contract against every Article 30 requirement in about seven seconds, which no human does. It is also wrong often enough that letting it set a compliance status would be indefensible in front of an auditor. So it never does. Every finding is labelled, carries a confidence value, and waits for a named person to accept or reject it. That decision, with the name and the timestamp, is what the audit trail records.
Compliance software is sold on trust, and the fastest way to lose it is a feature list that describes an intention. Our security page lists what is in production and nothing else. When something is not built, it is not on the page. When we cannot claim something yet, we say so plainly rather than hedging it into ambiguity.
The tempting way to price this is to put the Register behind the expensive tier. We did the opposite. Every plan runs a complete DORA programme, including the Register, Article 30 analysis, resilience testing and board reporting. What you pay more for is scale and automation, never the ability to comply.
Who it is for
Payment institutions and e-money institutions
Usually thirty to eighty ICT providers, a compliance lead who also owns three other regulations, and no appetite for a six-month implementation.
Small and mid-size banks
A real third-party risk function, an internal audit team that will ask where a number came from, and a Register that has to survive supervisory inspection.
Insurance undertakings and intermediaries
Often the furthest behind on ICT third-party risk, and the most exposed to concentration in a handful of core system providers.
Investment firms and asset managers
Lean teams, heavy reliance on outsourced technology, and a supervisor increasingly interested in the chain behind each provider.
If you have a dedicated third-party risk department, several hundred providers and a multi-entity group structure, talk to us about Enterprise, but be honest with yourself about whether a younger product is the right risk to take. We would rather tell you that now than in month four of an implementation.
How we build
Product decisions come from compliance officers, ICT risk managers and procurement leads describing what they actually do on a Tuesday, not from a control framework. When those two disagree, the Tuesday wins, because a control nobody performs is not a control.
We are deliberately early in the way we say so. There is no pretence of a large team behind the product, no invented customer logos, and no case study written before a customer existed. Penetration testing is carried out by DossierSec, a specialist security firm under the same ownership as Relynt, which the security page says plainly rather than calling it independent. Where we do not yet hold a certification, the security page says nothing rather than implying one.
The same discipline runs through the software. Backups are restored and verified on a schedule rather than assumed to work. Every sub-processor that touches customer data is published, including the one that runs outside the EU and how to switch it off. The incident response process states the windows in which we would tell you something went wrong.
None of that is remarkable. It is simply the standard a regulated buyer applies to its own vendors, applied to us.
See how one platform connects your ICT providers, assessments, evidence, contracts, risks and DORA Register.