Collect and validate vendor onboarding data, screen for sanctions and ownership risk, verify bank-detail changes out of band against a known contact, and hold what doesn't reconcile; vendor approval and payment release stay separate.
A new vendor or a bank-detail change arrives from the onboarding portal, a vendor email or a connected ERP feed.
02
The vendor's submission is normalised against the master-file schema, with its original fields kept.
Reason
03
A screening pass checks the vendor and its named owners against sanctions and watch lists.
04
The controller's configured onboarding rules and tax-form requirements are applied to the vendor type.
05
The vendor's existing, independently verified contact — never the one in the request — anchors the callback.
Decide
06
A name match, a shared address or an unresolved callback is flagged against the vendor, never cleared by the agent.
07
Every flagged vendor and every bank-detail change is routed to the named controller for disposition.
Out
08
The submission, the screening result, the callback outcome and the disposition are retained against the vendor.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
The agent proposes the change; the controller decides whether to release it, and payment release stays with a separate named person.
Example workflow
One vendor change, request to release
AgentHuman
1Request receivedVendor email, onboarding portal, ERP change form or connected intake
2Context assembledExisting record, prior verifications, screening history and configured rules
3Change screenedScreening result, ownership signal, callback status and confidence
4Controls appliedSanctions checks, ownership aggregation, callback verification and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing changes on the vendor record at any of them — the controller's lane opens at the confidence gate.
5DecisionBranches at the confidence threshold
High confidence
Goes to the controller to approve.
Low confidence
Adds a second verification pass first.
Controller approval
The change is held with its screening result, its callback outcome and the confidence.
Approve · Reject · Escalate to compliance
Approved — released to update▼
6Vendor-master system updatedOnly where write access and approval policy allow it
7Outcome evaluatedVerification accuracy, overrides, escalations and payment outcome
Overrides
Every controller override is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Approving a new vendor for payment.
Releasing a payment to any vendor.
Clearing a sanctions or watch-list hit.
Changing bank details on its own authority.
Automation boundaryAgent acts unaided
✓Collect and validate onboarding data and the required tax form.
✓Run screening and ownership aggregation against configured lists.
✓Verify bank-detail changes out of band against.
✓Flag what doesn't reconcile, and hold the record.
Any write happens inside the boundaries agreed at implementation, never ahead of approval.
Deciding a name match is a false positive.
Waiving the out-of-band callback.
Filing US beneficial-ownership reports.
Changes to screening rules or callback thresholds.
Example output
One vendor change, annotated
Everything the agent verifies is attached to the request it came from.
Verification output · single vendor changeIllustrative example
Vendor
Change requested
Payee-name check
Screening result
Confidence
Callback basis
Established vendor, new bank details
Bank-detail change received by email; routing and account both differ from the record
Close match
No direct hit — aggregate ownership under review
61%
Independently sourced contact, not the number in the request
As receivedTaken from the request and the existing vendor record — nothing on this side is inferred.
Evidence usedVerified contact on filePrior verified callbackPayee-name check
Why this holdA close match and an unresolved callback are evidence for the controller.
ActionApproveRejectEscalate to compliance
What the score decidesBelow the configured threshold the change picks up a second verification pass before.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every vendorFrom the vendor record on file
03Verification
Screen and verify from the record
Draw on the existing contact on file and the controller's configured screening rules.
01Approved path
A hit is not a decision
Under OFAC's ownership-aggregation rule, blocked ownership stacks across sanctions programmes — an entity can be blocked without appearing on any single list.
02Human review
Focus the controller on exceptions
Screening hits, ownership signals and unresolved callbacks are flagged, so the controller's read starts where fraud risk concentrates.
04Build an evidence trail
The change, the channel it was verified on and the officer who released it stay on the vendor record.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
An overall catch rate can look strong while one exposed vendor tier absorbs most of the attempts. Nestack reports the held-for-review rate by vendor tier, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Bank-change requests by email only
7.8%
4.0×
Review
New vendors onboarded under time pressure
5.6%
2.9×
Review
Vendors sharing an address or account
3.5%
1.8×
Watch
Established vendors, unchanged details
1.9%
0.8×
Normal
Bar: held-for-review-rate lift vs. the unchanged-vendor baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
Every cycle closes on a case, not an explanation
A cycle shuts when the missed impersonation is a case the next release has to catch. That suite is what the next bank change handled is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Held-for-review rate rises in a vendor tier.
02Diagnose
The bank-change email that read correctly is traced back to the callback that should have caught it, until the cause narrows to one.
03Improve
The change ships against a version, with the vendors that exposed it attached.
04Verify
A failing verification case holds the release until it clears.
05Learn
The case joins the standing suite and the callback rules move with it.
Learn → DetectThe return edge. The next bank change is checked against a suite one 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, verification workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Vendor workflow discovery and boundary definition.
02Vendor-master and payment-source review.
03Screening and verification-policy mapping and rule mapping.
04Submission ingestion and normalisation.
05Screening logic and ownership aggregation.
06Confidence scoring and callback routing.
07Controller approval workflow.
08Vendor-master and ERP integration.
09Bank-change regression cases.
10Guardrails and release controls.
11Vendor-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 vendor source, one entityProductionProduction vendor-master systemsAdvancedMultiple entities / systems
Introduced at Pilot
Screening and verification to your rules✓✓✓
Controller approval✓✓✓
Verification-accuracy baseline✓✓✓
Introduced at Production
Reporting by vendor group—✓✓
Approval workflow in your systems—✓✓
Approved write-back—✓✓
Vendor-master integration—✓✓
Introduced at Advanced
Multi-entity and multi-currency rules——✓
Multi-stage controller approvals——✓
High vendor volume——✓
Multi-entity vendor 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 vendor intake fields and master-file structure→Vendor-master ingestion and field mappingWeek 1
03Your screening rules and approved contact sources→Screening and verification-policy mappingWeek 1
04Access to relevant APIs, feeds or exports→Vendor-master and payment-source assessment, then integration setupWeek 2
05Changes you would not want released→Impersonation cases and the evaluation suiteWeek 4
06What no vendor change may skip→Confidence scoring, callback routing, guardrails and approval controlsWeek 3
07Named controllers to review flagged vendors→Controller approval 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
Each band sits on the weeks the work occupies, so week 5 runs evaluation and pilot together.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Vendor workflow discovery, policy mapping and the automation boundaryW2Source integration and the screening baselineW3Verification workflow, confidence logic and approval controlsW4Evaluation suite, guardrails and failure-mode testingW5Vendor-master integration, pilot vendors and targeted correctionsW6One payment cycle verified under the controller, then Agent Care handover
Reading the bandA bar covers only the weeks its work is named in. The week 5 overlap is real, not padding.
At the end of W6The final checks clear on live changes and monitoring moves to Agent Care.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Accounting AI agent
Build a vendor-master agent around your onboarding and verification chain.
Show us your vendor intake, your screening sources and who owns the callback. We'll map the verification workflow, set the automation boundary, and confirm where vendor approval ends and payment release begins.
