Payment method, autopay and due date change

How do we let a borrower change autopay or their payment method with the authorization captured and written to servicing?

Make the change a self-service request with the authorization in it. Callvu identifies the borrower, prefills the current payment method and schedule from servicing, takes the change (a new bank account, a new draft date within the rules, a switch to or from autopay, a one-time payment), captures the authorization the payment rules require on a process-controlled screen, applies the prenotification or validation the policy sets, writes the change to the servicing system, and confirms the next draft date and amount to the borrower.

In scopeSimpleCallvu moves: prefill, write back

Talk to an expert Try it in the sandbox

Last updated November 7, 2026.

The problem today

The borrower changed banks, told an agent, and the old account was drafted and returned.

Today, without Callvu

A borrower calls to update their autopay to a new account. The agent updates one system but not the draft schedule, or keys the account number wrong, or does not capture the authorization the ACH rules require for a recurring debit. The next draft fails, the borrower is charged a returned payment fee, and the loan shows a late payment.

Recurring debits need the borrower's authorization under the Nacha rules, retained by the originator; a change to the amount or date needs notice; the first debit to a new account is often validated. These are rules a process applies every time, and an agent applies sometimes.

The borrower can do this themselves in a minute on their phone, with the authorization captured properly.

How it runs

From the requestto the system of record.

A borrower asks to change their payment method or autopay in the app, on the web, on a call or through an AI agent. Callvu identifies the borrower and opens the request.

Borrower: Makes the change and authorizes on their own screen.
Servicing: Sees every change and handles exceptions in the Decision Desk.
Callvu: Identifies, prefills, captures the authorization, validates, writes to servicing and confirms.

Identify and prefill
The borrower is authenticated for the channel; the current payment method, the autopay status, the draft date and the amount are prefilled from the servicing system.
Capture the change and the authorization
The borrower enters the new account (validated for routing and account format), the draft date within the rules, and the autopay election; the recurring debit authorization with its required terms (amount or how it is determined, timing, how to revoke) is presented and authorized on a process-controlled screen with a timestamp.
Validate and decide
The policy's validation runs (a prenotification entry or an account verification); a failed validation is shown to the borrower to correct; a change that falls inside a payment's processing window, or a loan in a special status, goes to servicing in the Decision Desk.
Write back and confirm
The change and the authorization are written to the servicing system and the payment processor, and the confirmation with the next draft date and amount goes to the borrower; the authorization is retained for the period the rules require.

Where it ends: The borrower's payment method changed with the authorization captured and validated, servicing and the payment processor agree, and the next draft is confirmed. The Decision Trace shows the validation and the authorization; the Audit Trace shows the request, the authorization and the write.

Runtime enforcement

What is enforcedwhile the work runs.

The regulations preloaded in Callvu Studio and the bank's own policies, applied as steps that run, not lines in a binder. A step that breaks a rule does not run, so a completed run was compliant.

Regulations

NACHA rules on consumer debit authorizations (Nacha Operating Rules, Article Two, Subsection 2.3): An originator must obtain the consumer's authorization for a recurring debit entry, in writing or similarly authenticated, with the required terms (the amount or the method of determining it, the timing, and how to revoke), retain it for two years after termination, and provide notice of changes in the amount or date of recurring debits within the rule's periods; a prenotification may be used to validate the account.
Reg E preauthorized transfers (12 CFR 1005.10): Preauthorized electronic fund transfers from a consumer's account require written authorization with a copy to the consumer, notice of varying amounts, and the consumer's right to stop payment three business days before a scheduled transfer.
RESPA payment crediting (Reg X 12 CFR 1024.36 and Reg Z 12 CFR 1026.36(c)): Periodic payments are credited as of the day of receipt; the draft schedule must align with the due date so a conforming payment is not treated as late.

Company policies

A payment method change is captured from the borrower with the authorization the rules require; an agent cannot record it on their behalf.
Account validation runs before the first draft to a new account where the policy requires.
The servicing system and the payment processor are written together.
The authorization is retained for the required period.

Controls

Channel authentication and prefill from servicing.
Account format validation.
Authorization with required terms on a process-controlled screen.
Prenotification or verification.
Processing window check.
Single write and confirmation.

Clocks and deadlines

Change notice (Nacha and Reg E): Notice of a changed amount or date within the rules' periods before the debit.
Processing window: A change inside the next draft's processing window is applied to the following draft, with the borrower told.
Authorization retention: Two years after termination.

Documents and checks

The current method and schedule as prefilled
The change and the authorization with timestamp
The validation result
The servicing and processor writes and the confirmation

In the Decision Trace

The validation and its result.
The window check.
Any Decision Desk decision.

In the Audit Trace

The request and its channel.
The authorization event.
The writes and the confirmation.

The handoff

Between the front doorand the back office.

The front door

The app, the web, a call or an AI agent; the authorization on the borrower's own screen.

The back office

Servicing sees every change and decides only exceptions; the processor and servicing agree.

The Decision Desk

A change inside the processing window, a failed validation the borrower cannot correct, or a loan in a special status goes to servicing in the Decision Desk with only the allowed outcomes.

Proof

In scope.Proof at scale, not one process at a time.

The kind of process Callvu runs in production for customers in this industry. Ask for a reference on this exact process. The results below are the industry's published proof; each claim code links to its record on agents.callvu.com.

Bank Leumi runs its home lending workflows on Callvu.

MTG-01

Community Bank of Mississippi runs TRID loans on Callvu.

MTG-02

More than 1,000 processes are live across Callvu customers.

Across Callvu customers

Questions

What buyers ask next,answered plainly.

Can an agent change the account for the borrower?

No. The borrower makes the change and authorizes on their own screen, with the terms the rules require, and the authorization is retained.

What if the next draft is days away?

A change inside the processing window applies to the following draft and the borrower is told the exact date and amount.

Is the new account checked?

The format is validated at entry, and a prenotification or verification runs before the first draft where the policy requires.

Related processes

Servicing transfer notice Escrow analysis and shortage Repayment plans Servicemember protections request Try it in the sandbox All home lending processes

Bring this process, or the one that costs you most.

We build it against your policies and your systems, train your team and stay with you through launch. You are live in weeks.