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.
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
AgentHuman
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.
5DecisionBranches at the confidence threshold
High confidence
Goes to the ICT risk lead to review.
Low confidence
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 required8 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 boundaryAgent 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 arrangementIllustrative example
Arrangement
Function supported
Reference date
Template mapped to
Confidence
Supply-chain rank
Core banking hosting
Supports a critical or important function — card authorisation
31 Dec, prior year
Contractual arrangements
91%
Direct provider, rank one
As receivedTaken from the executed contract and the vendor master — nothing on this side is written by the agent.
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 aggregateIllustrative 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 threshold2 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 stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Incomplete entries rise in one function.
02Diagnose
The arrangement that supported a critical function and appeared in no register is traced back to one cause — a renewal nobody ever papered.
03Improve
The change is numbered on the way out, with the entries that revealed it.
04Verify
An entry case that has not cleared keeps the release parked until it does.
05Learn
It joins the suite for good, and the mapping rules are edited to match.
Learn → DetectThe 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.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Register workflow discovery and boundary definition.
02Contract and vendor-source assessment.
03Template, identifier and reference-date mapping.
04Arrangement ingestion and normalisation.
05Reconciliation and template-mapping logic.
06Confidence scoring and exception routing.
07ICT risk lead review workflow.
08Contract-repository and GRC integration.
09Entry and mapping cases.
10Guardrails and submission controls.
11Arrangement-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal 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 tierPilotOne entity, one registerProductionProduction contract systemsAdvancedMultiple 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 priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from buildBuild 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 bringWe build with it
01Your contract repository and vendor master→Arrangement ingestion and source mappingWeek 1
02Representative past register entries→Reconciliation baseline, identifier and source bindingWeek 2
03Your criticality policy and consolidation level→Template, identifier and reference-date mappingWeek 1
04Access to relevant APIs, feeds or exports→Contract and vendor-source assessment, then integration setupWeek 2
05Entries you would not want returned→Data-quality cases and the evaluation suiteWeek 4
06What no register entry may omit→Confidence scoring, exception routing, guardrails and approval controlsWeek 3
07Your named ICT risk lead, and the person who submits→Lead review workflow, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, 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.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Register workflow discovery, policy mapping and the automation boundaryW2Source integration and the reconciliation baselineW3Register workflow, mapping logic and review controlsW4Evaluation suite, data-quality checks and failure-mode testingW5GRC integration, pilot entities and targeted correctionsW6One submission window run under the ICT risk lead, then Agent Care handover
Reading the bandA bar covers the weeks its work is named in, and nothing else. The week 5 overlap is real, not padding.
At the end of W6Validation closes on a live window, and Agent Care assumes monitoring.
DurationSix-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.
