VeriRemit

A source-grounded payment agent that hard-blocks changed bank accounts until deterministic controls and a real human clear a signed release.

Comment 1

Inspiration

Vendor bank-detail changes are a classic payment-fraud problem: an invoice can look legitimate while one changed account number redirects a real payment.

VeriRemit is built around a stricter boundary: AI may investigate, explain, and orchestrate, but it never becomes the authority for a risky financial decision.

What it does

VeriRemit reviews a synthetic vendor-payment packet containing a vendor master, purchase order, previous invoice, current invoice, and bank-change letter.

A bounded reviewer powered by the OpenAI Agents SDK and Groq openai/gpt-oss-120b can inspect the case and call only four case-scoped tools. It cannot approve a bank change, sign a document, authorize payment, execute arbitrary HTTP requests, or run shell commands.

Nutrient extracts grounded facts from the source PDFs. Deterministic server-side policy then checks vendor identity, purchase order, amount, currency, beneficiary, extraction confidence, and bank-account continuity.

In the canonical case, every commercial check passes except one: the current invoice requests a different IBAN from the verified historical account. That creates a hard BLOCK.

The only path forward is an independent human callback using the trusted contact already stored in the vendor master. Contact information from the suspicious change notice is explicitly rejected.

Human approval does not erase the original BLOCK or rewrite the evidence. Instead, VeriRemit records a separate auditable verification exception that the server-side release gate can validate.

Only after that gate clears can VeriRemit generate and assemble a release packet. Doctavian produces the Payment Release Authorization from approved structured case data. Foxit then handles final document assembly and the human-signature boundary.

VeriRemit creates the Foxit eSign envelope, but only a real person can sign it. After signing, VeriRemit does not trust the browser redirect as proof of completion: it independently queries Foxit's authoritative provider state before the case can transition to RELEASE AUTHORIZED.

VeriRemit never executes a payment.

Sponsor architecture

  • Groq + OpenAI Agents SDK — bounded openai/gpt-oss-120b reviewer with only four case-scoped tools.
  • Nutrient Data Extraction API — grounded extraction with confidence, page, and source coordinates.
  • Nutrient DWS Viewer — short-lived, document-scoped read-only Viewer sessions for selected evidence.
  • Deterministic VeriRemit policy — normal server-side code owns PASS/BLOCK decisions and state transitions.
  • Trusted human callback — changed bank details cannot proceed without independent verification through the pre-existing vendor-master contact.
  • Doctavian — provider-native DOCX template using merge fields, repeated verification-control rows, and a calculated control count.
  • Foxit PDF Services via the official MCP server — reversible document upload/download operations through a statically allow-listed MCP surface. The live pdf_merge validation incompatibility is handled only through a narrow Foxit PDF Services compatibility path for that exact failure.
  • Foxit eSign API — direct human-signature handoff outside the agent's MCP tool catalog.
  • Tamper-evident audit chain — consequential events are SHA-256 hash-chained and re-verified before release and signature provider calls.

Where Nutrient DWS does the real work

Nutrient DWS is VeriRemit's evidence layer.

Data Extraction turns the five source PDFs into grounded, comparable facts with confidence, page, and source references. Those grounded facts feed deterministic cross-document checks rather than asking the model to guess whether a payment is safe.

For source review, VeriRemit can create a short-lived, read-only Viewer session scoped to the selected document. This lets reviewers trace consequential decisions back to source evidence instead of trusting an AI summary.

The live Nutrient proof completed both real extraction and real Viewer-session creation.

Where Doctavian does the real work

Doctavian is VeriRemit's approved-document generation layer.

After deterministic controls and the trusted human callback clear the release gate, VeriRemit sends approved structured case data into a provider-native DOCX template and receives the canonical Payment Release Authorization PDF.

The final generated authorization contains the ACME Components case, all ten verification-control rows with CONTROL COUNT: 10, the human-verification reference, amount, beneficiary, IBAN details, and the explicit no-payment-execution boundary.

The document is generated from approved structured data rather than free-written by the language model.

Where Foxit does the real work

Foxit owns the final document-assembly and human-signature boundary.

VeriRemit uses Foxit's official MCP server for reversible document operations and direct Foxit eSign for the consequential signature handoff.

Signing is intentionally absent from the agent's MCP capability surface. The agent may request an envelope only after the deterministic and human release gate has passed, and the signing-session URL is never returned to the language model.

The fresh canonical live run completed the complete human round trip: VeriRemit prepared the packet, created a real Foxit eSign session, a human signed the document, the server independently refreshed Foxit's authoritative provider state, and the case transitioned to RELEASE AUTHORIZED.

The audit chain remained verified throughout.

How I built it

VeriRemit is a TypeScript monorepo consisting of:

  • React + Vite reviewer workbench
  • Fastify long-lived agent/API service
  • OpenAI Agents SDK with Groq
  • deterministic policy and explicit state-machine packages
  • Nutrient Data Extraction + Viewer adapters
  • Doctavian structured document generation
  • Foxit MCP + narrow PDF Services compatibility boundary
  • direct Foxit eSign integration
  • append-only hash-chained audit records
  • deterministic synthetic PDF fixtures
  • Docker packaging
  • Playwright end-to-end coverage

The CREATED-state Groq tool-call path is also hardened against the provider's documented malformed failed_generation tool-call failure. VeriRemit retries only that specific failure once and continues to fail closed for rate limits, authentication errors, real provider/service failures, and deterministic denials.

Challenges

The hardest part was making the agent useful without making it authoritative.

Prompts can express intent, but prompts should not own safety invariants. Bank-account continuity is therefore evaluated in deterministic code. Human verification is a separate audited state transition. Structured generation cannot run until the release gate clears. Signing remains outside the agent's toolset. Only authoritative Foxit provider state can complete the workflow.

A second challenge was real provider compatibility.

Doctavian's working template needed to preserve the provider-native Maven Word package structure accepted by its live template reader.

Foxit's live MCP pdf_merge operation returned a validation incompatibility, so VeriRemit uses a deliberately narrow compatibility path through Foxit PDF Services for that exact failure instead of silently broadening fallback behavior. Reversible MCP upload/download operations remain on the official server surface.

Nutrient's extraction schema was likewise narrowed to the subset proven against the live API rather than preserving assumptions that only worked locally.

Accomplishments

  • A changed IBAN hard-blocks release even when every commercial field matches.
  • Human approval preserves the original deterministic BLOCK instead of rewriting history.
  • Suspicious change-letter contact information cannot become the trusted callback source.
  • Corrupting the audit chain disables consequential actions.
  • Structured document generation cannot run without approved release data.
  • Doctavian output contains ten repeated verification controls and CONTROL COUNT: 10.
  • Foxit signing is absent from the agent's MCP capability surface.
  • Signing-session URLs are never exposed to the language model.
  • Final authorization requires authoritative Foxit completion, not a browser redirect.
  • The real Groq bounded-reviewer flow passed.
  • Real Nutrient extraction and Viewer-session creation passed.
  • Real Doctavian generation and PDF download passed.
  • Real Foxit packet assembly completed through the verified MCP/PDF Services boundary.
  • Real Foxit eSign envelope creation and human signing passed.
  • Authoritative Foxit completion moved the case to RELEASE AUTHORIZED.
  • Final merged main CI passes 142/142 tests, strict TypeScript checks, production build, secret scan, Chromium end-to-end tests, Docker build, and container health verification.

What I learned

Agent safety becomes easier to reason about when authority is moved out of the prompt.

Prompts explain intent. Deterministic code owns invariants. State machines own transitions. Provider adapters own external contracts. Structured generation owns the approved document. Humans own the decisions that should remain human.

The project also reinforced a practical integration lesson: real provider contracts matter more than assumptions. Template structure, schema restrictions, MCP behavior, and provider completion states all had to be verified against the live systems rather than inferred from local mocks.

What's next

The commercial wedge is accounts-payable teams handling vendor bank-detail changes, where a single fraudulent update can create a high-value loss and existing approval workflows often lack source-grounded verification plus an independently auditable human-signature boundary.

A post-hackathon VeriRemit would add configurable accounts-payable policy packs, ERP and vendor-master integrations, authenticated multi-user workflows, durable transactional storage, independent callback workflows, and externally anchored audit evidence.

Built With

  • docker
  • doctavian
  • fastify
  • foxit-esign
  • foxit-pdf-services-mcp
  • groq
  • nutrient-dws
  • openai-agents-sdk
  • openai/gpt-oss-120b
  • playwright
  • react
  • typescript
  • vite
Share this project:

Updates

Submission history