Batch credit-transfer, ACH, direct-debit, mandate, and file-processing architecture

Corporate, biller, or channel originator

Creates a bulk credit-transfer or direct-debit instruction and its control totals.

Kind

actor

Owner

Corporate treasury, biller, or bank channel

Responsibilities

• Authorise the batch and each business purpose
• Provide stable file, group, and transaction identifiers

Inputs

• Payroll, supplier payments, collections, mandate data

Outputs

• Authorised payment file or batch API request

Controls

• Entitlement
• Dual approval
• File and amount totals
• Mandate evidence for direct debit

Failure modes

• Duplicate file
• Invalid control total
• Missing mandate

Recovery

• Reject before acceptance
• Correct under a new controlled version without changing original evidence

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Managed file and batch-ingestion service

Authenticates, scans, validates, counts, and stores the immutable inbound batch.

Kind

gateway

Owner

Corporate channels and payment platform

Responsibilities

• Verify channel and file integrity
• Apply file-level and transaction-level validation
• Create an immutable ingestion record

Inputs

• Signed or authenticated file
• Control totals

Outputs

• Accepted batch with item statuses

Controls

• Malware scan
• Checksum
• Duplicate-file key
• Count and value reconciliation

Failure modes

• Corrupt file
• Partial upload
• Schema or profile failure

Recovery

• Reject the file atomically where the contract requires
• Preserve item-level status where partial acceptance is supported

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Mandate and authorisation service

For direct debit, proves the creditor’s authority and applies scheme-specific mandate conditions.

Kind

control

Owner

Collections product and mandate operations

Responsibilities

• Store or reference mandate evidence
• Validate mandate status, sequence, and amendment

Inputs

• Mandate identifier
• Debtor, creditor, dates, sequence

Outputs

• Mandate-valid collection or precise rejection

Controls

• Mandate status
• Creditor identifier
• Sequence and date rules
• Audit

Failure modes

• Cancelled or missing mandate
• Wrong sequence
• Unauthorised amendment

Recovery

• Reject or return according to the scheme
• Correct mandate data only from authoritative evidence

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Cut-off, calendar, and batch scheduler

Assigns accepted items to the correct clearing window and value date.

Kind

service

Owner

Payment product and batch operations

Responsibilities

• Apply calendars, lead times, and cut-offs
• Group items without losing transaction identity

Inputs

• Accepted items
• Requested dates
• Scheme calendars

Outputs

• Release-ready clearing batch

Controls

• Effective-date calendar
• Cut-off enforcement
• Late-file treatment

Failure modes

• Missed cut-off
• Closed business day
• Misapplied value date

Recovery

• Move to the next permitted cycle with explicit status
• Do not backdate silently

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Batch clearing and item validation

Validates participant batches, calculates obligations, and returns file and transaction outcomes.

Kind

external-network

Owner

Clearing-system operator

Responsibilities

• Validate file and item eligibility
• Calculate clearing obligations
• Distribute accepted items and statuses

Inputs

• Participant batch

Outputs

• Accepted/rejected items, participant obligations, output files

Controls

• Participant status
• File sequence
• Control totals
• Transaction validation

Failure modes

• File rejection
• Item rejection
• Unbalanced cycle
• Late input

Recovery

• Return precise statuses
• Recalculate from immutable accepted inputs
• Apply cycle-continuity rules

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Batch net-settlement service

Settles participant net obligations in the designated settlement asset.

Kind

ledger

Owner

Central bank or designated settlement institution

Responsibilities

• Receive balanced obligations
• Post net debits and credits
• Return finality evidence

Inputs

• Net settlement file or obligation set

Outputs

• Settled participant positions

Controls

• Balanced totals
• Funding
• Atomic cycle posting
• Finality timestamp

Failure modes

• Participant cannot fund
• Settlement file mismatch
• Ledger outage

Recovery

• Apply the documented default or unwind process
• Reconcile the cycle before reopening

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Receiving-bank posting and returns

Posts accepted credits or debits, produces returns, and preserves the original clearing references.

Kind

application

Owner

Receiving payment and account operations

Responsibilities

• Post eligible customer items
• Return rejected or unpaid items within applicable windows
• Report item outcomes

Inputs

• Clearing output
• Settlement evidence
• Account and mandate state

Outputs

• Customer posting
• Return
• Status and reporting

Controls

• Account validation
• Posting idempotency
• Return reason and deadline

Failure modes

• Insufficient funds
• Closed account
• Duplicate posting
• Late return

Recovery

• Use the scheme return or refund process
• Reconcile customer and settlement books before adjustment

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

File, item, settlement, and customer reconciliation

Proves that every accepted item has one final business, settlement, and ledger outcome.

Kind

operations

Owner

Payment operations and finance control

Responsibilities

• Reconcile file totals to item statuses
• Reconcile clearing obligations to settlement
• Reconcile returns and customer postings

Inputs

• Inbound file
• Acknowledgements
• Clearing output
• Settlement report
• Customer postings

Outputs

• Closed batch, open exception, and audit evidence

Controls

• File/group/item identifiers
• Count and value totals
• Aged-break ownership

Failure modes

• Missing output file
• Count/value mismatch
• Orphan return

Recovery

• Rebuild from immutable records
• Repair the affected item only
• Never rebatch a settled item blindly

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Authorised payment file

batch-originator → batch-ingestion

Carry complete batch and item identifiers with control totals.

Contract

file · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

A partial or corrupt upload is not treated as an accepted batch.

Collection mandate check

batch-ingestion → batch-mandate

Validate authority for direct-debit items before scheduling.

Contract

control · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

A mandate failure is attached to the item and follows the scheme's file/item response model.

Accepted credit items

batch-ingestion → batch-scheduler

Schedule accepted credit-transfer items by value date and cut-off.

Contract

event · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Late items receive an explicit next action rather than a hidden date change.

Mandate-valid debit items

batch-mandate → batch-scheduler

Schedule authorised collections under scheme lead-time and sequence rules.

Contract

event · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Invalid mandate state prevents release.

Clearing batch

batch-scheduler → batch-clearing

Submit the release-ready batch with reconciled counts and value.

Contract

file · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Unknown submission outcome is reconciled by file reference before retransmission.

Net obligations

batch-clearing → batch-settlement

Settle balanced participant obligations for the completed cycle.

Contract

settlement · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Funding or obligation mismatch follows the documented default and cycle process.

Cleared items and statuses

batch-clearing → batch-receiver

Deliver accepted customer items and precise rejects to receiving participants.

Contract

file · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

A missing or duplicate output file is reconciled before posting.

Cycle settlement evidence

batch-settlement → batch-receiver

Prove the participant settlement position used by posting policy.

Contract

event · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Delayed evidence remains distinct from item acceptance.

Postings, rejects, and returns

batch-receiver → batch-reconciliation

Close each original item against customer and exception outcomes.

Contract

file · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

An unmatched return remains an exception and cannot alter an unrelated item.

Immutable intake totals

batch-ingestion → batch-reconciliation

Provide the original file, group, item, count, and value baseline.

Contract

event · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

If baseline integrity fails, the batch cannot be certified complete.

One payroll file through clearing and settlement

Follow a pain.001 file from corporate approval through file validation, scheduling, clearing, net settlement, beneficiary posting, and multi-level reconciliation.

1. Corporate approves the payroll file — File authorised. The originator supplies file, group, and transaction identifiers plus count and value totals.
2. Bank accepts the immutable batch — File accepted. Authentication, integrity, duplicate, schema/profile, count, and value checks pass.
3. Items enter the permitted cycle — Scheduled. The current calendar, cut-off, and requested value date select the release window.
4. Clearing accepts eligible items — Cleared. File and item outcomes are returned without losing original identifiers.
5. Net obligations settle — Cycle settled. The designated settlement ledger posts balanced participant obligations.
6. Beneficiary items post — Customer items posted. Receiving institutions post accepted items once under their scheme and account controls.
7. Every level reconciles — Batch closed. File, group, transaction, clearing, settlement, customer, and return totals agree.

Duplicate file with changed filename

The same business batch is uploaded again under a different transport filename.

Last confirmed state

Original batch identity must be established before accepting the new upload.

Settlement

Depends on the original batch; the duplicate itself has no separate settlement authority.

Funds and entries

Do not create a second set of customer or settlement postings.

Next owner

Corporate channel and batch operations

Safe action

Compare business identifiers, control totals, and content checksum; reject or hold the duplicate under the channel contract.

Evidence required

• File and group identifiers
• Content checksum
• Counts and value
• Original status

Recovery

• Establish original outcome
• Return duplicate status
• Submit a corrected batch only under the documented correction process

Participant cannot fund net obligation

The clearing cycle calculates a debit obligation the participant cannot settle.

Last confirmed state

Items cleared; cycle settlement not final.

Settlement

Not settled until the default or liquidity process completes.

Funds and entries

Customer availability must follow the scheme's provisional/final treatment and participant policy.

Next owner

Clearing operator, settlement institution, and participant treasury

Safe action

Apply the documented funding, default, or unwind process; do not edit obligations manually.

Evidence required

• Accepted cycle inputs
• Net obligation
• Funding position
• Default-rule decision

Recovery

• Fund or apply default process
• Recalculate if the rules require
• Distribute final outcomes and reconcile

Return cannot match the original item

A receiving participant sends a return with missing or inconsistent original references.

Last confirmed state

Original item settled and posted or rejected; return identity is uncertain.

Settlement

Original cycle settlement remains final; return is a new linked transaction when valid.

Funds and entries

No customer recredit or debit occurs until the return is matched and authorised.

Next owner

Payment reconciliation and exceptions operations

Safe action

Hold the return in an exception queue and match by permitted original references and value evidence.

Evidence required

• Original transaction identifiers
• Amount and currency
• Return reason
• Participant and settlement references

Recovery

• Resolve the match
• Post the return once
• Escalate or reject an unresolvable return under scheme rules

Should a file fail as one unit or allow item-level acceptance?

• Atomic file — Simple control totals and correction, but one bad item can delay every valid item.
• Item-level acceptance — More valid payments proceed, but status, correction, and reconciliation become more complex.

Follow the channel and scheme contract. Record both file and item states so neither acceptance model produces invisible gaps.

When should customer postings follow a net cycle?

• After final cycle settlement — Clear settlement evidence but later availability.
• Provisional or risk-based posting — Earlier availability with explicit participant credit and reversal exposure.

Separate clearing acceptance, settlement finality, and customer posting in the state model even if a rail normally makes them appear together.