Introduce Bulk/Batch Payments in V2.2
OFP-001 agreed how Bulk/Batch Payments will work: the payments travel as a JSON array in one signed request, not as an uploaded file. This proposal asks whether to deliver them in V2.2. It recommends that LFIs MUST support Bulk/Batch for SME and Corporate accounts, and MAY offer it for Retail accounts.
Cast your vote
Sign in with the Trust Framework to vote — For, Against, or Abstain — recorded in the open with your reasoning. Your organisation and name come from your directory profile, and each person may vote once. Three questions are attached to this vote — set out in section 05 below. The first asks LFIs whether they can deliver on the V2.2 timeline; the second asks TPPs how large their batches are; the third asks both whether the split between business and Retail accounts is right.
The model is agreed; the timing is not
Bulk/Batch Payments — called File Payments in the specification — have been defined since v1.2 as a file upload. A TPP uploads a payment file in an LFI-specific format to POST /payment-consents/{ConsentId}/file, references it by hash on the consent, and then creates the batch with POST /file-payments. No LFI in the ecosystem has implemented these endpoints, and Bulk/Batch Payments are not yet documented for V2.2.
OFP-001 replaced the file with a JSON array. The create request carries one Instructions[] element per payment, built from the single-payment fields the standard already defines, and is signed end-to-end like POST /payments. The consent drops FileType, FileHash and FileReference, adds a customer-facing Description, and keeps NumberOfTransactions, ControlSum and RequestedExecutionDate.
This proposal does not reopen that model. It asks two questions that OFP-001 left open: should Bulk/Batch Payments be delivered in V2.2, and which LFIs must support them.
Bulk/Batch in V2.2, mandatory for business accounts
Deliver Bulk/Batch Payments in V2.2 on the OFP-001 model. Every LFI supports them for SME and Corporate accounts; Retail support is the LFI’s choice.
- Bulk/Batch Payments are part of V2.2, using the JSON array model agreed in OFP-001. The file-upload model is not part of V2.2.
- An LFI MUST support Bulk/Batch Payments for SME and Corporate accounts — accounts whose
AccountTypeisSMEorCorporate. - An LFI MAY support Bulk/Batch Payments for Retail accounts. Where it does not, it MUST NOT offer a Retail account as the debtor account when the User authorises a Bulk/Batch consent. If the User holds no eligible account, the LFI MUST tell the User so, and the User returns to the TPP with the consent rejected.
- Bulk and Batch are one capability. The TPP sends one consent and one array of instructions. Whether the LFI posts one debit for the total or one debit per instruction is the LFI’s decision.
- The API Hub validates the batch. Before the request reaches the LFI, the API Hub checks that the number of
InstructionsequalsNumberOfTransactionsand that the sum of their amounts equalsControlSum, and rejects the request if either check fails. - Multi-authorisation is unchanged. Where a business account needs more than one approver, the existing multi-authorization flow applies to a Bulk/Batch consent as it does to any other payment consent.
# 1 - TPP stages the consent at POST /par
"authorization_details": [{
"type": "urn:openfinanceuae:service-initiation-consent:v2.2",
"consent": {
"ConsentId": "pcon_8821",
"ControlParameters": {
"ConsentSchedule": {
"FilePayment": {
"Description": "Payroll June 2026",
"NumberOfTransactions": 250,
"ControlSum": "125000.00",
"RequestedExecutionDate": "2026-06-28"
}
}
},
...
}
}]
# 2 - The User authorises at the LFI, debiting an SME or Corporate account
# 3 - TPP creates the batch at POST /file-payments (signed JWS)
{
"Data": {
"ConsentId": "pcon_8821",
"PaymentPurposeCode": "SALA",
"OpenFinanceBilling": { ... },
"Instructions": [ { ... }, { ... } ] # 250 elements, as agreed in OFP-001
}
}
# The API Hub checks Instructions.length == 250 and sum(Amount) == 125000.00
# before the request is proxied to the LFI.
# 4 - TPP tracks the batch at GET /file-payments/{PaymentId}Why now, and why business accounts
The cost that kept Bulk/Batch unbuilt has gone. Under the file model, each LFI had to accept files in its own formats, scan them for malware, and protect the PII held in them, with no specification for any of it. OFP-001 removes all of that. What remains is one JSON endpoint built from fields LFIs already implement for single payments.
Business accounts are where batches happen. Payroll, supplier runs and disbursements are made from SME and Corporate accounts. Making Bulk/Batch mandatory for those accounts gives a TPP serving businesses the same capability at every LFI.
Retail demand is less clear. Few Retail Users pay many creditors at once. Leaving Retail optional lets an LFI offer it where it sees demand without requiring every LFI to build and support it.
What changes
The OFP-001 drafts move into the V2.2 specifications, and the file-only endpoints are removed.
uae-bank-initiation-openapi.yamlRemove POST /payment-consents/{ConsentId}/file. Replace the POST /file-payments request body with the OFP-001 Instructions[] request, and set the maxItems of Instructions from the answers to question 02. GET /file-payments/{PaymentId} and GET /file-payments/{PaymentId}/report stay; the report’s format is aligned to the JSON model as part of the V2.2 specification work.
uae-authorization-endpoints-openapi.yamlApply the OFP-001 changes to ControlParameters.ConsentSchedule.FilePayment: remove FileType, FileHash and FileReference; add Description.
Store the Bulk/Batch consent like any other payment consent. On POST /file-payments, validate the request against the schema and the array against NumberOfTransactions and ControlSum, then proxy it to the LFI.
uae-ozone-connect-bank-service-initiation-openapi.yamlThe LFI receives the batch on its Ozone Connect POST /payments endpoint, whose file-payment request body is replaced by the array. The Ozone Connect POST /payment-consents and POST /payment-consents/{consentId}/file endpoints are removed. They exist only so the LFI can validate an uploaded file before authorisation; with no file to upload, the consent is held only in the API Hub, as for every other payment type. The LFI’s authorisation journey shows the batch’s Description, number of payments, total and execution date, and offers only eligible debtor accounts.
Add Bulk/Batch Payment pages to the V2.2 TPP Standards and LFI API Hub guides, update the payment status note that says Bulk/Batch is not yet documented in V2.2, and add a V2.2 changelog entry.
Three questions, asked with the vote
These appear as optional boxes when you confirm your vote.
Can you support Bulk/Batch Payments for SME and Corporate accounts in V2.2? Do you plan to offer them for Retail accounts as well?
This confirms that the mandatory scope can be delivered on the V2.2 timeline, and tells TPPs early which LFIs intend to offer Retail Bulk/Batch.
What would you use Bulk/Batch Payments for, and how many payments do you expect in one batch? Is a maximum of 5,000 instructions per request enough?
OFP-001 drafted Instructions[] with a maximum of 5,000 elements and left the final figure open. The answers set the limit in the V2.2 specification.
Is the split right: mandatory for SME and Corporate accounts, optional for Retail accounts?
The split decides which LFIs must build Bulk/Batch for V2.2, and how far TPPs can rely on it across the ecosystem.
What delivering in V2.2 buys
- ✓Businesses can run payroll and supplier payments through Open Finance from V2.2, without waiting for a later release.
- ✓The design is settled. OFP-001 agreed the JSON array model, which reuses the single-payment fields LFIs already implement.
- ✓TPPs get a known baseline: every LFI supports Bulk/Batch for SME and Corporate accounts.
- ✓There is no file handling to build: nothing to parse, scan for malware, or negotiate formats for.
- ✓The API Hub checks each batch against NumberOfTransactions and ControlSum, so LFIs do not each build that check.
- ✓LFIs that see no Retail demand do not have to offer Bulk/Batch to Retail accounts.
What it costs
- ×Every LFI with SME or Corporate customers must build Bulk/Batch for V2.2: the Ozone Connect endpoint, the authorisation journey, and processing of the instructions.
- ×Because Retail support is optional, a TPP cannot assume Retail Bulk/Batch at every LFI.
- ×One JSON request is bounded by request-size limits, so the maximum batch size has to be fixed and very large runs split across several consents.
- ×Back-office files (ISO 20022 pain.001, CSV) must be mapped to JSON by the TPP before submission.
- ×Leaving debit posting to the LFI means a business may see one debit for the total at one LFI and one debit per payment at another.