Credit Transfer Batches

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. Atlar makes batch processing simple, reliable, and easy to track across supported banks and payment schemes.

Batch processing offers several advantages:

• More efficient for high-volume or recurring payouts
• Consistent metadata across all included payments
• Unified status tracking and reconciliation for the entire batch

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

Credit transfer batch status

Each credit transfer batch is assigned a status upon creation, indicating where it is in the processing flow.

Viewing batch details

Double-click a credit transfer batch to open the detailed view. This includes:

• Details – Batch ID, file size, number of payments, total amount, and more
• Errors – If the batch failed or partially failed, this tab shows what needs to be corrected in the file
• Results – If the batch completed or partially failed, the created payments can be viewed and accessed here
• Approval chains – Shows who approved the batch and in what order

Note: The Approval Chains view will be empty if batch-level approval is not used. For payments handled at the individual level (e.g. from your ERP), approval is managed outside of Atlar.

Creating a credit transfer batch

A credit transfer batch can be created automatically from your ERP system, via the Atlar API, or manually by uploading a CSV file in the Atlar platform in the Credit Transfer Batches tab. The following sections explain how to manually upload a CSV file.

CSV file format

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

Fields

The table below lists all supported fields, along with their required status and format. Some fields are conditionally required depending on the values of other fields. If any row in the file requires a field, that field must also be included in the header row.

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

Inlining destination account

Instead of referencing pre-existing external accounts and counterparties by ID, you can inline destination account information directly in the CSV file. This is done by setting destination.type to INLINE and including the necessary destination fields, such as destination.market, destination.holder.legalName, etc.

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

When a batch with INLINE content is processed, new external accounts and counterparties will be created unless an exact match already exists. To match, both the destination.holder.legalName and account details (number and routing) must be identical to an existing resource.

Examples

The following example 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 this section .

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 that are marked as 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.