Banking AI agent · ICT register
ICT Third-Party Register & Oversight AI Agent
Maintain the DORA register of information across your EU/EEA entities, reconcile it against the contract, vendor and spend records as at the reference date, and hold the pack for the person who submits.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Named submitter
- EU/EEA only
- After launch
- Agent Care
What this agent does
Assembles the return, not the accountability
In
- 01
A contract is signed, and the agent opens an entry from the contract, vendor, spend and application records.
- 02
A counterparty resolves to one legal entity and one identifier, and the source lists are shown where they disagree.
Reason
- 03
An arrangement is mapped onto the templates prescribed by Implementing Regulation (EU) 2024/2956, field by field.
- 04
A reference date is fixed at 31 December of the preceding year, and the entry is drawn as at it, not at assembly.
- 05
A window opens: the CSSF ran a full 2026 collection while the FSMA ran only a limited update that same year.
Decide
- 06
A function is classified critical or important by a named owner, and the agent shows the contract set that attaches.
- 07
A subcontractor is recorded only where it underpins an ICT service supporting a critical or important function.
Out
- 08
A pack is assembled with its reconciliation exceptions attached, and held for the person who submits it.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
The management body is accountable under Article 5 and a named person submits; a register filed with a gap is the entity's defective return.
Example workflow
One arrangement, contract to submission
- 1Arrangement identifiedContract repository, vendor master, spend ledger or application inventory
- 2Facts assembledCounterparty identifiers, service description, function supported and locations, each with its source
- 3Entry draftedTemplate fields, supply-chain rank, gaps and confidence
- 4Controls appliedReference-date checks, identifier checks, subcontractor population rules and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing is submitted at any of them — the agent is reconciling, and the ICT risk lead's lane opens at the confidence gate.
Goes to the ICT risk lead to review.
Adds a legal and procurement read first.
ICT risk lead review
The entry is held with its sources, the fields it cannot fill and the confidence.
Accept · Amend · Send to legal review
Accepted — into the submission pack
- 6Register record updatedOnly where write access and approval policy allow it
- 7Outcome evaluatedValidation results, amendments, authority feedback and post-submission corrections
Amendments
Every lead amendment is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Submitting the register to a competent authority.
- Determining a critical or important function.
- Owning the residual risk on an arrangement.
- Approving a provider's subcontracting change.
Automation boundary
Agent acts unaided
- ✓Assemble entries on the prescribed templates from your records.
- ✓Reconcile each entry against the internal source lists.
- ✓Draw the register as at the configured reference date.
- ✓Flag what an entry is missing, and hold it for the lead for the named owner.
Any write happens inside the boundaries agreed at implementation, never ahead of the submitter.
- Signing off the annual management-body review.
- Deciding the level of consolidation for a group.
- Filling a key field the entity cannot populate.
- Changes to mapping, template or submission rules.
Example output
One arrangement, annotated
Few registers cleared every check in the ESAs' 2024 voluntary dry run — this is that layer.
Register entry · single arrangement
Illustrative example- Arrangement
- Core banking hosting
- Function supported
- Supports a critical or important function — card authorisation
- Reference date
- 31 Dec, prior year
- Template mapped to
- Contractual arrangements
- Confidence
- 91%
- Supply-chain rank
- Direct provider, rank one
As received
Taken from the executed contract and the vendor master — nothing on this side is written by the agent.
Evidence held
- Executed contract
- Vendor-master record
- Application inventory
Why this classification
It was set by the named owner under the entity's own policy and a person still decides.
What the score decides
Below the configured threshold the entry picks up a legal read before it reaches the lead.
Action
AcceptAmendSend to legal reviewValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Every arrangement
From the contract record
Assemble from the records
Draw on the entity's records and the window its authority runs ahead of 31 March to the ESAs.
The register is a filed return
The US third-party guidance creates no filed return; this is the European obligation.
Send review to the contested entries
Unmatched counterparties and low-confidence entries are marked, so the lead's read starts where the lists disagree.
Build an evidence trail
The arrangement, the template field it was mapped to and the person who submitted stay on the entry.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Contract and CLM
- Icertis
- Ironclad
- SAP Ariba
- Coupa
Third-party risk
- Archer
- MetricStream
- Prevalent
- OneTrust
ERP and spend
- SAP
- Oracle Fusion
- Workday
- Coupa spend
Agent
ICT third-party register & oversight
- Reads the records
- Reconciles the entries
- Holds for the lead
CMDB and applications
- ServiceNow CMDB
- LeanIX
- Flexera
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and the return
Six checks, one folded inside the next. Whatever clears the last is written into the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether an entry may stand
- L3
- Puts the pack in the lead's hands
- L4 – L5
- Keep the arrangement and the template field behind it
- L6
- Narrows to entry reporting when signals degrade
How Nestack evaluates it
Evaluate the register workflow — not only the file that validates.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the return the designations are built from
- E1Final-output evaluationDid every field in the entry match the record behind it?
- E2Step-level evaluationDid the agent use the right reference date, template and identifier?
- E3Tool evaluationDid it read the correct contract and the correct source system?
- E4Confidence calibrationDo low-confidence entries actually attract more lead amendments?
- E5Slice evaluationHow does performance change across specific supported functions?
- E6Business outcomeHow many entries needed a lead amendment or a later correction?
Floor — the outcome the entity answers for
Failure modes
Where each failure originates in the agent
Seven failure modes, placed at the stage each one originates.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- DI-03
Contract system taken as truth
An arrangement never papered as a contract never appears.
Stage gathers
Contracts, vendor master, spend and applications
02 · Reasoning
2 modes
- DI-04
Inherited criticality flag
Last year's classification is copied onto a changed arrangement.
- DI-06
Over-recorded supply chain
Subcontractors underpinning nothing critical fill the templates.
Stage proposes
Template fields, sources, gaps and confidence
03 · Tool / write
2 modes
- DI-02
Key field auto-filled
A field the entity cannot populate is given a plausible value.
- DI-05
Consolidation level wrong
The same arrangement is counted at parent and subsidiary.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- DI-01
Assembled at the wrong date
Live systems are read instead of the reference date.
Stage returns
The register the entity submits under its own name
05 · Change / Version
1 mode
- DI-07
Silent mapping drift
A model or rule change narrows what the agent records.
Stage tracks
Model, prompt, mapping rules and template config
- Sev-1 · entry submitted outside the boundary
- Sev-2 · a wrong entry reaches the return
- Sev-3 · source degrades, entry goes to review
Affected slices
Near-miss is the normal state of this return
A group-level entry-completeness figure is set by the functions with the simplest chains, while the critical ones carry the gaps. Nestack reports the incomplete-entry rate by function, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Payments and settlement | 8.1% | 3.6× | Review | |
| Core banking hosting | 6.4% | 2.8× | Review | |
| Trading and market data | 3.9% | 1.7× | Watch | |
| Internal corporate systems | 2.1% | 0.9× | Normal |
Bar: incomplete-entry-rate lift vs. internal-systems baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
Each cycle closes with a new entry case
A cycle shuts when the incomplete entry is a case the next release has to catch. That suite is what the next register submitted is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Incomplete entries rise in one function.
- 02
Diagnose
The arrangement that supported a critical function and appeared in no register is traced back to one cause — a renewal nobody ever papered.
- 03
Improve
The change is numbered on the way out, with the entries that revealed it.
- 04
Verify
An entry case that has not cleared keeps the release parked until it does.
- 05
Learn
It joins the suite for good, and the mapping rules are edited to match.
Learn → Detect
The return edge. The next detection runs against a suite one entry case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, register workflow, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Register workflow discovery and boundary definition.Week 1
- 02Contract and vendor-source assessment.Week 1, Week 2
- 03Template, identifier and reference-date mapping.Week 1, Week 2
- 04Arrangement ingestion and normalisation.Week 2
- 05Reconciliation and template-mapping logic.Week 2, Week 3
- 06Confidence scoring and exception routing.Week 3
- 07ICT risk lead review workflow.Week 3, Week 4
- 08Contract-repository and GRC integration.Week 5
- 09Entry and mapping cases.Week 4, Week 5
- 10Guardrails and submission controls.Week 4
- 11Arrangement-trail instrumentation.Week 5, Week 6
- 12Deployment, documentation and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
| Capability✓ in scope · — not at this tier | PilotOne entity, one register | ProductionProduction contract systems | AdvancedMultiple entities / jurisdictions |
|---|---|---|---|
| Introduced at Pilot | |||
| Assembly to your records and templates | ✓ | ✓ | ✓ |
| ICT risk lead review | ✓ | ✓ | ✓ |
| Entry-completeness baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by function | — | ✓ | ✓ |
| Review workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Contract-repository integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-jurisdiction window rules | — | — | ✓ |
| Multi-stage group approvals | — | — | ✓ |
| High arrangement volume | — | — | ✓ |
| Multi-entity register controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
- Separate from build
- Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bring
We build with it
01Your contract repository and vendor master
→Arrangement ingestion and source mapping
Week 102Representative past register entries
→Reconciliation baseline, identifier and source binding
Week 203Your criticality policy and consolidation level
→Template, identifier and reference-date mapping
Week 104Access to relevant APIs, feeds or exports
→Contract and vendor-source assessment, then integration setup
Week 205Entries you would not want returned
→Data-quality cases and the evaluation suite
Week 406What no register entry may omit
→Confidence scoring, exception routing, guardrails and approval controls
Week 307Your named ICT risk lead, and the person who submits
→Lead review workflow, then pilot and production validation
Weeks 5–6
Nothing else is required
Deployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Bands sit where the submission window puts them, which is why the fifth carries two phases at once.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Register workflow discovery, policy mapping and the automation boundary
W2Source integration and the reconciliation baseline
W3Register workflow, mapping logic and review controls
W4Evaluation suite, data-quality checks and failure-mode testing
W5GRC integration, pilot entities and targeted corrections
W6One submission window run under the ICT risk lead, then Agent Care handover
- Reading the band
- A bar covers the weeks its work is named in, and nothing else. The week 5 overlap is real, not padding.
- At the end of W6
- Validation closes on a live window, and Agent Care assumes monitoring.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Banking AI agent
Build a register agent around the return your entity files.
Show us your contract repository, your criticality policy and who submits. You get one reconciled register per entity, its gaps dated before the window closes, and a trail of what was known if one surfaces later.
- Typical delivery
- 4–6 weeks
- Deployment
- Your contract stack
- Named submitter
- EU/EEA only
- After launch
- Agent Care available
Nestack Agents · ICT third-party register
AGT-BK-20 · Agent Care available after launch