Third-party risk · Periodic review
RelayBanking operationsPeriodic third-party risk reviews, prepared by a Relay
Most third-party reviews stall on paperwork: expired certificates, unread reports and evidence nobody has chased. A Relay can do the preparation while the risk owner keeps the decision.
Valnora & Elric team6 min read
Third-party risk teams rarely struggle with the framework. They struggle with the calendar. A bank with a few hundred vendors has reviews coming due every week, each needing a contract check, a fresh assurance report, a look at recent incidents and a conversation with the business owner. The analysis takes an hour. Collecting the inputs takes a fortnight.
These notes answer the questions teams ask when they consider handing that preparation to a Relay, an AI coworker in Agent Serve with its own instructions, access and approval rules.
What part of a vendor review should a Relay take on?
The preparation, and nothing past it. Supervisors describe the third-party life cycle in similar terms across regimes: planning, due diligence, contracting, ongoing monitoring and exit. The US interagency guidance from 2023 sets it out that way, and the EU’s Digital Operational Resilience Act puts ongoing oversight of ICT providers on a legal footing. Most of the recurring effort sits in ongoing monitoring.
A good split looks like this:
- The Relay finds reviews coming due, reads what is on file, checks for public news, lists what is missing and drafts the request for it.
- The vendor owner answers questions about how the service is actually used.
- The risk owner rates residual risk, agrees actions and decides whether the relationship continues.
How does the Relay know a review is due?
It watches the vendor register. In Agent Serve the register is a table with a row per vendor: tier, owner, services supported, next review date and status. A watch on that table polls on an interval you choose, from every minute to once a day, and you describe in plain language what needs attention, for example “tier 1 or 2 vendors whose next review date is within 30 days”.
Watches never write to the source, and the Relay has no workflow here that writes to the register. That is deliberate. The register stays the record your risk owners maintain, and the Relay cannot quietly mark a review complete.
For a monthly portfolio summary, add a second responsibility on a schedule, such as 08:00 on the first day of each month.
What does it read before it writes anything?
Three sources, each connected through its tool group:
- The vendor file. Contracts, data processing terms, assurance reports and past review notes sit in a Knowledge Base, tagged by vendor. The Relay searches it the way an analyst would skim a folder.
- The register itself. A read-only query gives tier, owner and open actions.
- The public web. The web tool looks for recent outages, breaches or enforcement involving the vendor, and the pack cites each link it found.
Your third-party risk policy goes into the Knowledge Base too, so the pack follows your review template rather than a generic checklist.
A Relay that prepares each vendor review
Relay · Vendor review preparer
- 01Review coming dueA watch on the vendor register table, polled daily, picks up rows whose next review date is close.
- 02Read the fileIt searches the contract, assurance reports and last review in the Knowledge Base.
- 03Check public newsThe web tool looks for recent public reports about the vendor, such as outages or enforcement.
- 04Write the review packA pack with gaps, expiring evidence and questions, saved to the library after approval.
- 05Evidence requestAn email to the vendor owner asking for missing documents, sent only once someone approves it.
People and data
- 06Vendor registerTiering, owner, services, review dates and status. The Relay reads it and never writes to it.
- 07Vendor ownerSupplies evidence and answers questions about how the service is used.
- 08Risk owner decidesRates residual risk, agrees actions and updates the register.
What does the review pack look like?
What the solution produces
Vendor review pack (illustrative)
Record- Vendor
- Cloud document storage provider · tier 1 · supports a critical service
- Review due
- In 21 days. Last review closed with two open actions.
- Evidence on file
- Contract and data processing terms current. Independent assurance report covers a period that ended 14 months ago.
- Gaps
- No updated assurance report. No exit plan test recorded since onboarding. One open action from last review has no owner.
- Public news
- One reported regional outage in the last quarter. No enforcement found.
- Questions for the owner
- Did the outage affect our service? Has the subcontractor list changed?
Evidence request to the vendor owner (illustrative)
MessageSubject: Annual review of the document storage provider, due in 21 days
Hi, the review pack is in the library under Vendor reviews. Two items are missing before the risk owner can complete it:
1. The latest independent assurance report from the provider.
2. Confirmation of whether the regional outage last quarter affected our service.
Could you send these by the 18th? Reply here with any questions.
The pack is short on purpose. It states what is on file, what has expired, what is missing and what to ask. The most useful line is often the plainest: an assurance report that covers a period long past, or an exit plan that was never tested.
At the Assist autonomy level the Relay asks for approval before it saves the pack to the library, in a folder such as “Vendor reviews”. If your team would rather receive packs in Chat, the Relay can instead report the result into the risk owner’s conversation with it, which needs no approval.
How does chasing evidence stay under control?
Every email waits for approval, under every autonomy setting. The approval is tied to the exact message the reviewer saw. If anyone changes a word, it needs a fresh review. Approvals expire after 24 hours by default, and you can name up to 20 approvers, so a request does not wait on one person’s holiday.
Two further settings narrow the risk:
- Recipient policy. Set it to internal only, so the Relay writes to your own vendor owners and never to the vendor directly. Use an allowlist if a few vendor contacts should be reachable.
- Sender. Send from a shared workspace inbox or a team mailbox in Gmail or Outlook, not a person’s account.
Every proposal, approval, decline and sent message is written to the audit log.
Controls and governance
Approvals before action
Relays never send email or book meetings without an approval, under any autonomy setting. An approval covers the exact payload the reviewer saw and expires if nobody decides.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
SSO and SCIM
Sign in through your identity provider with SAML 2.0 or OIDC, and provision people with SCIM.
Self-hosting
Run Agent Serve in your own cloud or data centre, next to the systems it reads.
Bring your own keys
Use your organisation’s own model provider keys at organisation or workspace level.
Row-level access
Row-level policies narrow what each person sees in tables, dashboards, exports and scheduled reports.
More on how Agent Serve handles access, data and audit on the security page.
Where does it stop?
At the decision. The Relay does not rate vendors, close actions, approve exceptions or update the register. It also has limits worth knowing when you plan the rollout: it runs up to two tasks at once and 25 a day, which suits a weekly flow of reviews but not a one-off backfill of your whole portfolio. For a backfill, a workflow built in the workflow builder that loops over the register is the better tool.
If you want a portfolio view, a dashboard on the register shows reviews due, overdue and by tier, and the Relay can be pointed at it to summarise the month.
How should a team start?
Pick your tier 1 vendors only. Load their files into the Knowledge Base, set the watch, and keep the Relay at Assist so every saved pack and every email is approved. Run it for one review cycle and compare its packs with what analysts would have prepared. Most teams find the gap list is the part they keep. If you also map policies to controls, the policy-to-control mapping setup gives the Relay a clearer picture of which controls a vendor supports.
Questions teams ask
Does the Relay rate the vendor?
No. It prepares the evidence and lists gaps. The residual risk rating, the actions and the decision to continue, remediate or exit stay with the risk owner.
Can it update the vendor register itself?
Not directly. Relays read tables, and writes to tables go through a workflow the Relay runs. In this setup the risk owner updates the register; if you want automation, allow a separate workflow with its own approval step.
Will it email vendors directly?
Only if you allow it. Set the recipient policy to internal only and every message goes to your own vendor owners. Whatever the policy, each email waits for approval.
What you need
- A vendor register with tier, owner, services supported and next review date for each vendor
- Contracts, assurance reports and past review notes, uploaded to a Knowledge Base per vendor
- Your third-party risk policy and review templates, so the pack follows your format
- A shared library folder for review packs that risk owners can open
- Named approvers for evidence requests, usually the third-party risk team
- Agreement on which recipients the Relay may email, set as an internal-only or allowlist policy