# Payments & financial operations: enterprise AI policy pack

Use agents for reconciliation and workflow preparation without allowing autonomous payments, bank-detail changes, excessive refunds or changes to posted books.

Implementation guidance, not executable Tracelet configuration or legal advice. Tool names identify places where the control may apply; they do not claim shipped connector coverage. Confirm actual tool/action coverage and enforce destination permissions. Replace example thresholds, IDs and approval windows with your approved values.

## Control scope

- Protected assets: Bank accounts, payees, payment instructions, refunds, ledgers, close periods and merchant routing
- Consequential actions: Payee change, money movement, refund, write-off, journal mutation and payment configuration change
- Applicable systems: ERP, treasury, expense, payroll and payment-provider platforms
- Context to resolve: Resolve legal entity, live/test mode, actor, payee history, bank fingerprint, amount, currency, cumulative exposure, invoice and approval chain.
- Enforcement boundary: Keep payment execution and master-data credentials outside general assistants. Execute through the finance system’s maker-checker workflow and preserve its immutable transaction record.

## Owners

Financial controller + treasury or payments owner

## Configure first

- Legal entities, live versus test tenants, currencies, payees and delegated authority thresholds
- Two-person approval matrix, new-payee cooling period and sanctions/fraud checks
- Closed accounting periods, protected ledgers and payment-provider configuration owners

## Shared decision baseline

### Resolve the real target

Decide on immutable IDs and effective context: principal, tenant/account, environment, resource, data classification and destination. Names and local profiles are hints, not authority.

### Fail closed on consequential ambiguity

If the target, blast radius, tenant or data classification cannot be resolved, hold the action. Do not treat missing metadata as non-production or low risk.

### Bind approval to the exact action

An approval covers the actor, operation, target set, content or artifact digest, value and expiry. Material changes invalidate it; the requester cannot approve their own action.

### Keep an evidence-grade decision record

Record resolved context, policy version, matched rule, decision, approver and downstream result. Minimise captured sensitive content and protect the record from the acting identity.

## Policies

### FO-01: Block autonomous payee and bank-detail changes

- Severity: Critical
- Decision: Block
- Owner: Treasury or accounts-payable master-data owner

#### Policy statement

Deny agents from directly creating payees or changing bank account, beneficiary, wallet or payout details in a live financial system.

#### Covered operations

- Create or activate payee/vendor
- Change bank routing, account, IBAN, wallet or payout destination
- Alter verification status or bypass cooling period

#### Evaluation rules

- Resolve legal entity, payee master record, previous destination fingerprint, verification source and actor.
- Treat a bank-detail change followed by payment as one high-risk sequence, even across systems or sessions.
- Do not accept instructions or verification evidence solely from the same email, document or chat being acted upon.

#### Example decisions (illustrative; do not run against live systems)

- **ERP:** `Replace vendor bank account using details from an inbound email`. Block direct execution.
- **Stripe Connect:** `Change a live connected account payout destination`. Block and use verified human workflow.

#### Applicable tools and systems

- SAP
- Oracle ERP
- NetSuite
- Microsoft Dynamics 365
- Workday
- Stripe Connect
- Adyen
- Treasury platforms

#### Enforcement

Keep supplier/payee master-data authority outside agent credentials. Route changes through verified call-back, maker-checker and cooling-period controls in the system of record.

#### Exception / approval

No direct agent exception. Two authorised humans verify through an independent channel and execute in the finance workflow.

#### Test fixtures

- Should remain permitted: Prepare a payee-change request with redacted comparison data for human verification.
- Should be blocked or held: Apply the change, bypass verification or submit a payment to the newly supplied destination.

#### Implementation references

- [NIST · AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)

### FO-02: Require two-person approval for consequential money movement

- Severity: Critical
- Decision: Require two-person approval
- Owner: Treasury or payments owner

#### Policy statement

Hold payment, transfer, payout, payroll or disbursement instructions that involve a new payee, exceed delegated value or velocity limits, or create material cumulative exposure.

#### Covered operations

- Create, approve, release or schedule payment
- Transfer between accounts or initiate payout
- Run payroll or bulk disbursement
- Retry or split transactions after decline/hold

#### Evaluation rules

- Resolve live/test mode, legal entity, amount/currency, base-currency value, payee history, destination fingerprint and supporting obligation.
- Aggregate by payee, actor and time window to prevent threshold splitting and duplicate payment.
- Require two eligible approvers, neither the requester, and preserve the destination system’s maker-checker control.
- Use idempotency and duplicate detection; a retry must reference the original transaction intent.

#### Example decisions (illustrative; do not run against live systems)

- **NetSuite / ERP:** `Release a $250,000 payment batch`. Hold for two-person approval.
- **Stripe:** `Retry a payout request with a new idempotency key`. Hold as a potential duplicate.

#### Applicable tools and systems

- SAP
- Oracle ERP
- NetSuite
- Stripe
- Adyen
- PayPal / Braintree
- Banking portals
- Payroll platforms

#### Enforcement

Use a finance-owned execution identity, destination-native dual approval, transaction limits and idempotency/duplicate controls. The agent can prepare but cannot be a maker and checker.

#### Exception / approval

Emergency payment follows the documented financial authority matrix; approval binds to payee fingerprint, amount, currency and transaction identifier.

#### Test fixtures

- Should remain permitted: Create a draft payment within preparation permissions without releasing funds.
- Should be blocked or held: Release without two approvers, split around limits, change payee after approval or create a duplicate via retry.

#### Implementation references

- [Stripe · Idempotent requests](https://docs.stripe.com/api/idempotent_requests)

### FO-03: Review refunds, credits and write-offs beyond delegated authority

- Severity: High
- Decision: Require approval
- Owner: Revenue or support finance owner

#### Policy statement

Hold refunds, service credits, credit notes and write-offs that exceed the operator’s single-action or cumulative limit, lack a valid source transaction, or change destination.

#### Covered operations

- Create refund or credit note
- Write off receivable or waive fee
- Issue manual credit outside the original payment path
- Repeat partial actions that cumulatively exceed authority

#### Evaluation rules

- Resolve original transaction, customer/tenant, amount remaining, currency, reason code and refund destination.
- Aggregate by operator, customer and original charge to detect split or duplicate credits.
- Require approval for destination changes and never send a refund to unverified alternate payment details.

#### Example decisions (illustrative; do not run against live systems)

- **Stripe:** `Refund the full live charge after two prior partial refunds`. Hold when cumulative amount exceeds authority.
- **ERP:** `Write off a receivable with no linked dispute or approval`. Hold.

#### Applicable tools and systems

- Stripe
- Adyen
- PayPal / Braintree
- Salesforce
- Zendesk
- NetSuite
- SAP
- Oracle ERP

#### Enforcement

Use provider/ERP roles, cumulative limits and a broker that links the decision to the original transaction. Record the downstream refund or credit identifier.

#### Exception / approval

Approval covers source transaction, total cumulative value, destination and reason; changed values require reapproval.

#### Test fixtures

- Should remain permitted: Issue one valid refund within delegated authority to the original payment method.
- Should be blocked or held: Change destination, exceed cumulative limit, refund more than the remaining amount or reuse approval for another charge.

#### Implementation references

- [Stripe · Refunds API](https://docs.stripe.com/api/refunds)

### FO-04: Block deletion or silent rewrite of posted financial records

- Severity: Critical
- Decision: Block
- Owner: Financial controller

#### Policy statement

Deny deletion, overwrite or backdating of posted journals, settled transactions, invoices and audit records, and deny reopening a closed period through an agent identity.

#### Covered operations

- Delete or edit posted journal/transaction
- Reopen or change close status of accounting period
- Backdate record into a closed period
- Delete reconciliation or audit evidence

#### Evaluation rules

- Resolve legal entity, ledger, posting status, close period, source transaction and audit implications.
- Require corrections through reversal and compensating entry, preserving linkage to the original.
- Keep period-close and audit-record administration outside the agent’s finance role.

#### Example decisions (illustrative; do not run against live systems)

- **ERP:** `Delete a posted journal from the closed quarter`. Block; use reversal workflow.
- **Accounting platform:** `Reopen FY26-Q4 to backdate an adjustment`. Block direct agent execution.

#### Applicable tools and systems

- SAP
- Oracle ERP
- NetSuite
- Microsoft Dynamics 365
- Xero
- QuickBooks Online
- Workday Financial Management

#### Enforcement

Use ledger permissions, close locks, append-only audit records and correction workflows in the financial system. Monitor attempts from all API and UI paths.

#### Exception / approval

Period reopening is a controller-led workflow with documented rationale, independent approval and auditor-visible record; not an agent override.

#### Test fixtures

- Should remain permitted: Prepare a reversing journal in an open period for authorised review.
- Should be blocked or held: Delete or overwrite the original, reopen the period or remove evidence of the change.

#### Implementation references

- [NIST · AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)

### FO-05: Require dual control for live payment-routing configuration

- Severity: Critical
- Decision: Require two-person approval
- Owner: Payments platform owner + financial controller

#### Policy statement

Hold changes to live merchant accounts, settlement destinations, webhook endpoints, signing secrets, fraud rules and payment-routing configuration.

#### Covered operations

- Change settlement bank or merchant ownership
- Rotate/reveal webhook signing secret or change endpoint
- Change fraud thresholds, routing rules or live/test mode
- Disable reconciliation or notification controls

#### Evaluation rules

- Resolve platform account, legal entity, live/test mode, current and proposed destination/configuration and downstream dependencies.
- Require payments and security/finance approval where credential, routing or fraud posture changes.
- Bind approval to the exact configuration diff and verify post-change callbacks/reconciliation.

#### Example decisions (illustrative; do not run against live systems)

- **Payment provider:** `Point live webhooks at a new domain and reveal a new signing secret`. Hold for payments and security approval.
- **Merchant portal:** `Change settlement destination for the production entity`. Hold for dual control.

#### Applicable tools and systems

- Stripe
- Adyen
- PayPal / Braintree
- Checkout.com
- Banking gateways
- ERP payment connectors
- Fraud platforms

#### Enforcement

Use provider-native restricted roles and approval where available; otherwise broker writes through a finance/security-owned service and verify the resulting configuration independently.

#### Exception / approval

Incident changes remain dual-controlled, exact-diff approved and time-bound with mandatory post-change verification.

#### Test fixtures

- Should remain permitted: Read live configuration or change test-mode routing within delegated scope.
- Should be blocked or held: Change live settlement, weaken fraud controls, reveal signing material or alter approved values before execution.

#### Implementation references

- [Stripe · Idempotent requests](https://docs.stripe.com/api/idempotent_requests)

## Rollout checklist

- [ ] Inventory authoritative resource IDs, environments, classifications and owners.
- [ ] Map every entry point: IDE, agent, CLI, MCP, API, browser and direct console.
- [ ] Put the hard deny or least-privilege boundary in the destination system.
- [ ] Test permitted, held and denied fixtures using synthetic data in a sandbox.
- [ ] Test aliases, APIs, batch operations, changed approvals, retries and unknown scope.
- [ ] Observe matches, tune false positives and then enforce a bounded production scope.

Coverage: https://tracelet.ai/platform#coverage