Credit Transfer Batches

Process multiple payments at once.
A credit transfer batch is a group of outgoing payments submitted together.
Instead of creating individual payments one by one, you send a single batch containing multiple payment instructions.

Batch processing offers several advantages:

• Efficiency – Ideal for high-volume or recurring payouts
• Consistency – Apply the same metadata across all included payments
• Unified tracking – Monitor the entire batch with a single status

The Credit Transfer Batches tab shows all batches submitted through a CSV upload in the Atlar platform or via your ERP / API.

Batch Status

Each credit transfer batch receives a status indicating its place in the processing flow.

Viewing Batch Details

Double-click a credit transfer batch to open its detailed view, which includes:

• Details – Batch ID, file size, number of payments, total amount, and more
• Errors – Lists issues if the batch failed or partially failed
• Results – Shows the created payments for completed or partially failed batches
• Approval chains – Displays who approved the batch and in what order

Creating a Credit Transfer Batch

You can create a batch:

• Automatically from your ERP system
• Through the Atlar API
• Manually by uploading a CSV file in the Credit Transfer Batches tab

The steps below explain how to upload a CSV file manually.

CSV File Format

The CSV file must include a header row.
Some field names are always required, while others are optional or conditionally required.

For example, if any row specifies INLINE for destination.type, then fields such as
destination.market, destination.holder.legalName, and
destination.identifier.{type,market,number} must be present in the header.

Supported Fields

Inlining Destination Account

Instead of referencing existing external accounts or counterparties by ID,
you can inline the destination account directly by setting destination.type to INLINE and including the necessary fields.

Inline Data Example

amount.currency,amount.stringValue,date,scheme,reference,source.type,source.id,destination.type,destination.market,destination.holder.legalName,destination.identifier.type,destination.identifier.market,destination.identifier.number,destination.bic
USD,123.45,2024-01-23,CROSS_BORDER,invoice-no.205,ACCOUNT,d89b7f42-62b9-47d2-8969-0743f32ebc0d,INLINE,US,John Smith,NUMBER,US,123456789012,CHASUS33XXX

Inline Behaviour & Examples

When a batch with INLINE content is processed, the destination details from the file are used for that payment only. No counterparty or external account is looked up or created, and the payment is not linked to a saved counterparty.

Under the previous behaviour (available until 31 March 2027 for organisations that have not switched yet), Atlar instead matches an existing counterparty and external account when both destination.holder.legalName and account details (number and routing) are identical, or creates new ones if no match is found.

Mixed Example CSV

The example below demonstrates a mix of functionality:

• Inline destination account information
• Referencing existing destination account resources
• Specifying routing information (e.g. sort code, BIC, ABA)
• Optional fields like externalId and metadata.<key>

amount.currency,amount.stringValue,date,scheme,reference,externalId,source.type,source.id,destination.type,destination.id,destination.market,destination.holder.legalName,destination.identifier.type,destination.identifier.market,destination.identifier.number,destination.bic,destination.routing.type,destination.routing.number,metadata.comment,metadata.my-id
SEK,12.34,2024-02-20,SE_GIRO,invoice-no.119,,ACCOUNT,d73067c3-5427-40b5-b63b-76f89acb5a72,INLINE,,SE,anders andersson,SE_BANKGIRO,SE,12345678,,,,,
DKK,51.35,2024-02-20,DK_A2A,invoice-no.120,,ACCOUNT,57f6dcce-a4f9-4fc7-b496-182c4df0a60c,ACCOUNT,eb2ba9c1-ec7d-43e2-8724-9c85af870308,,,,,,,,,,
EUR,2.00,2024-02-20,SCT,invoice-no.121,,ACCOUNT,d89b7f42-62b9-47d2-8969-0743f32ebc0d,EXTERNAL_ACCOUNT,31380a97-f54b-4ae3-8f7e-3541c2914db6,,,,,,,,,,
GBP,531.42,2024-02-20,GB_CT_FPS,invoice-no.122,,ACCOUNT,5755d02f-0937-492b-adf3-c045cc4e0fa9,INLINE,,GB,John Doe,NUMBER,GB,12345678,,GB_DSC,123456,this is the payment for xyz,21743612948719284
USD,123.45,2024-02-20,CROSS_BORDER,invoice-no.123,,ACCOUNT,5755d02f-0937-492b-adf3-c045cc4e0fa9,INLINE,,US,John Smith,NUMBER,US,123456789012,BOFAUS3NXXX,US_ABA,123456789,"use the metadata fields, to set anything you would like",129572198421

See more example scenarios and required fields in Batch Payments → Example Scenarios.

Metadata Fields

You can include multiple metadata keys by specifying them as separate columns in the format metadata.<your-key>.

...,metadata.comment,metadata.my-id
...,"My comment #1",my-id-123
...,"My comment #2",my-id-456

Example Scenarios with Inlined Destination Account

The tables below illustrate which optional fields must be populated for certain schemes when using inlined destination account information.
These tables focus only on fields marked optional in the fields table; all required fields must still be included.

Cross-border Payment to the UK

When sending a cross-border payment to the UK with an IBAN.

UK Domestic Faster Payments (FPS)

For domestic GBP payments using the Faster Payments scheme with account number and sort code.

Cross-border Payment to the US

When sending funds to the US using account number and ABA routing.

Cross-border Payment to India

For cross-border payments to India, regulatory reporting is required.

SEPA Credit Transfer

For domestic or intra-EU euro payments using IBAN.