Changes and prenotes

A notification of change tells the originating bank that an entry posted but its details need correcting. A prenotification is a zero-dollar entry that tests an account before live entries follow.

A notification of change arrives

An RDFI sends the notification as a COR entry in a file the bank receives. The bank records it as an ACH Change with direction inbound and status received, and publishes payments.ach_change.received.

change_code and change_reason are the Nacha code and its title. corrected holds the fields read out of the raw corrected_data.
When original_trace matches an entry the bank originated, the change carries transfer_id and customer_id, and its routing_number and account_number are the ones that entry was sent to.
If that entry was a prenotification, its prenote_status becomes changed.

`change_code`	Fields in `corrected`
`C01`	`account_number`
`C02`	`routing_number`
`C03`	`routing_number`, `account_number`
`C04`	`name`
`C05`	`transaction_code`
`C06`	`account_number`, `transaction_code`
`C07`	`routing_number`, `account_number`, `transaction_code`
`C09`	`individual_id`

How the correction is applied

The caller does nothing. On the next transfer from the same customer to the same routing_number and account_number, the bank replaces the counterparty's fields with the corrected ones before the entry is stored. The transfer's change_id names the change, the response shows the counterparty as it will be sent, and the change becomes applied with payments.ach_change.applied. Later entries to the old details are corrected by the most recent change that is received or applied.

A corrected routing number, account number or name replaces the one sent. A corrected transaction code sets account_type. A corrected individual_id is recorded and not carried onto later entries. Update your own records from the response.

Refusing a change

POST /ach-changes/{id}/refuse takes a refused_code from C61 to C69 and an operator. It needs payments:write, or the staff scope payments:operations:write. Only an inbound change that is received or applied can be refused, within fifteen days of receipt; otherwise the answer is conflict. The bank sends the RDFI a refusal file, and the change becomes refused with refused_code, refused_reason and refused_file_id. It is no longer applied to new entries.

Changes the bank sends

As the RDFI, the bank raises one kind itself. When a received entry carries the transaction code of the other account type, the entry still posts and the ODFI is sent a C05 with the code the account needs. That change has direction outbound, status sent and the receipt_id of the entry. If the ODFI refuses it, the status becomes refused. GET /ach-changes filters by customer_id, direction, status and transfer_id.

Prenotifications

Send prenote: true with an amount of 0. Any other amount is refused, and so is a zero amount without prenote. The entry is screened and filed like any other, under a prenotification transaction code. It places no hold, posts nothing and does not count against the originator's limits.

`prenote_status`	Meaning
`pending`	Set at creation. The RDFI has not answered and its time has not run out.
`verified`	The prenotification settled, and three banking days have passed since its effective date with no answer.
`returned`	The RDFI returned it. The transfer's `status` is `returned` as well.
`changed`	The RDFI answered with a notification of change.

A scheduler routine marks prenotifications verified. Operations can run the same check at POST /rails/ach/prenote-verifications, which answers the number verified.

The wait is enforced only for an originator whose prenote_required is true. Its live entries need a verified prenotification from the same customer to the same routing and account number; without one the answer is 422 with payments.prenote_required. Other originators may prenote, and their live entries do not wait.

In a sandbox

POST /simulate/transfers/ach/change plays the RDFI. It takes the trace_number of an originated entry, a change_code from C01 to C14 and the corrected fields that code needs, and answers the change recorded. To receive a prenotification, call POST /simulate/transfers/ach/receive with prenote: true and an amount of 0. The receipt's outcome is accepted when the account is open.