Requests for Proof of Authorization (POA) Guide

• When a POA is required

• What forms of POA are acceptable by transaction type, consent method, and SEC code

When a POA Request Is Triggered

A POA request is initiated whenever we need to produce documented, Nacha-compliant evidence that a specific transaction was authorized. The three primary triggers:

1. Over-limit holds (transaction-level)

Triggered when a transaction is held for review because it exceeds an Account's approved processing limits.

• Required POA artifact: Full authorization record for the specific held transaction (authorization language, consent timestamp, identity/auth signal, bank account reference). Target: ASAP to prevent delay of processing, but within 24 hrs (biz day)

• SLA: Straddle to release the next ACH window after compliant POA is received, no interruption in funding time if POA is received the same biz day before ACH windows close.

2. Bank requests tied to customer disputes

Triggered when the ODFI (sponsor bank) or RDFI requests proof of authorization in response to a consumer or business dispute, a return (e.g., R05, R07, R10, R29, R51), or a written statement of unauthorized debit (WSUD).

• Required POA artifact: Authorization record plus associated transaction history, IP/device signals, and any revocation correspondence.

• SLA: Dictated by the bank's request. Most WSUD responses must be returned to the bank within 10 banking days of the request. Ops must surface the request to Compliance immediately on receipt.

3. Spot checks and audits

Triggered proactively by:

• Straddle sponsor bank annual ACH audits

• Internal compliance reviews (quarterly sampling)

• Nacha Rules Compliance Audit (annual, required for all Originators and Third-Party Senders)

• Ad-hoc requests from Straddle, sponsor banks, or regulators

• Required POA artifact: Full authorization record for the sampled transactions, including authentication evidence for WEB entries.

• SLA: As specified by the requestor; typically 5 business days.

What Counts as Acceptable POA

The acceptable form of POA depends on two variables:

1. How authorization was obtained — internet (electronic) vs. signed (including e-signature)

2. Who is the Receiver — consumer vs. business

This pairing drives both the SEC code on the ACH entry and the documented standard we must meet.

Decision matrix by consent method and party

Required elements for a WEB (internet-consent) POA

For any transaction authorized via web or mobile, the POA package must contain all of the following:

1. Authorization language — the exact text the Receiver consented to, visible on screen at the time of consent. Must include:

   • Express authorization to debit (and, where applicable, credit) the account

   • Amount and frequency (single, recurring, or subsequent/standing)

   • Receiver's right to revoke and the method for doing so

   • Business name and support contact

2. Authentication record — evidence identifying the Receiver and demonstrating consent, linked to the authorization event. Accepted forms:

   • Digital signature

   • Secure code or PIN

   • Shared secret (e.g., account credential pass-through)

   • Biometric verification

3. Transaction-specific metadata:

   • Date and timestamp of consent

   • Receiver's IP address and device details

   • Email and/or phone used

   • Bank name and last 4 of account

   • Item purchased / reason for debit

4. Client/account identifiers — name on account, shipping/billing address, any additional identity verification controls used.

5. Receipt — evidence that a receipt or confirmation was provided to the Receiver (email send log, on-screen confirmation capture).

Required elements for a signed (PPD/CCD) POA

1. Executed authorization or agreement — original or e-signed copy. For CCD, a trading partner agreement that binds the Receiver to Nacha Operating Rules is sufficient; explicit per-transaction authorization is not required but the agreement must address authorization.

2. Clear, legible terms — amount, frequency, revocation method, and the business name.

3. Counterparty identification — full legal entity name (for B2B) or full consumer name and account info.

4. Signature evidence — wet signature image, e-signature certificate, or equivalent audit trail.