# June 2026 (/changelog/2026-06)



{/* GENERATED by scripts/gen-changelog.mjs from content/changelog.mdx — do not edit. */}

## Jun 26, 2026 [#jun-26-2026]

### New Bank & Payment Types Supported [#new-bank--payment-types-supported]

We published payment rules for [Maybank Singapore (H2H)](/guides/mbb-sg-payments). The page covers field validation and constraints for the FAST, PAYNOW, GIRO, and BKTR payment types.

#### Link to payment rules: [#link-to-payment-rules]

* [Acme Maybank Singapore Payments (H2H)](/guides/mbb-sg-payments)

***

## Jun 25, 2026 [#jun-25-2026]

### Documentation: OCBC Singapore Payment Rules Corrected [#documentation-ocbc-singapore-payment-rules-corrected]

We corrected and expanded the [OCBC Singapore payment rules](/guides/ocbc-sg-payments) to match Acme's validation. The validation behavior is unchanged. These updates correct the documentation.

* FAST/GIRO `receiver.name` allows up to 140 characters. It was previously stated as 35.
* MEPS and TT `customerReference` allows up to 16 characters. It was previously stated as 25.
* PAYNOW now lists the mandatory `receiver.name` field (SWIFT, up to 140 characters).
* PAYNOW `receiver.proxyType` now lists `NRIC` as a supported value.
* PAYNOW `receiver.proxyValue` formats were corrected for MOBILE, UEN, and VPA, and an NRIC format was added.
* PAYNOW (FAST) and PAYNOW\_GIRO are now documented as separate payment types. `VPA` is only supported for PAYNOW (FAST).
* TT `receiver.address` is mandatory. It was previously stated as optional.
* TT now lists the optional `receiver.localRoutingIdentifier` field (alphanumeric, up to 35 characters).
* MEPS now lists the optional `receiver.intermediaryBank` field (BIC11).
* We documented the supported currencies, the GIRO and PAYNOW\_GIRO payment date rule, and the FAST and PAYNOW (FAST) amount limit.

#### Link to updated payment rules: [#link-to-updated-payment-rules]

* [Acme OCBC Bank Singapore Payments (H2H)](/guides/ocbc-sg-payments)

***

## Jun 24, 2026 [#jun-24-2026]

### New Bank & Payment Types Supported [#new-bank--payment-types-supported-1]

Added support for **Standard Chartered Bank** [single payments](/reference/post-payments) with the following payment types:

SCB SG:

* FAST (Fast and Secure Transfers) — real-time interbank fund transfer (IBFT) via the FAST network
* MEPS (MAS Electronic Payment System) — high-value SGD interbank transfers
* BKTR (Intra-Account Funds Transfer) — book transfer between accounts within SCB Singapore.
* TT (Telegraphic Transfer) — cross-border international SWIFT transfer.

SCB GB:

* GB\_FPS (Faster Payment System) - real-time interbank fund transfer (IBFT) via the FPS network
* GB\_CHAPS (Real Time Gross Settlement) - same-day high-value local bank transfer via the Real Time Gross Settlement system
* GB\_SEPA (Single Euro Payments Area)- Payyments between SEPA countries. ACH(SEPA) payment is an electronic fund transfer to the payee’s account for low-value and bulk volume.
* BKTR (Intra-Account Funds Transfer) — book transfer between accounts within SCB GB.
* TT (Telegraphic Transfer) — cross-border international SWIFT transfer.

#### Links to new payment rules: [#links-to-new-payment-rules]

* [Acme Standard Chartered Bank Singapore Payments (API)](/guides/scb-sg-api-payments)
* [Acme Standard Chartered Bank Great Britain Payments (API)](/guides/scb-gb-api-payments)

***

## Jun 16, 2026 [#jun-16-2026]

### Enhancement: DBS Singapore API Updates [#enhancement-dbs-singapore-api-updates]

#### The DBS Singapore Payment API now forwards bank charge instructions to DBS for MEPS and TT APIs. [#the-dbs-singapore-payment-api-now-forwards-bank-charge-instructions-to-dbs-for-meps-and-tt-apis]

* `bankChargeBearer` accepts `SENDER`, `RECEIVER`, or `SHARED` and is now forwarded to DBS. Previously it was accepted but not sent, so DBS applied its default.
* New optional `chargeAccount` field sets the account DBS debits for the bank charges. When omitted, DBS debits the originating account.

#### The DBS Singapore Payment API now accepts an optional `paymentDetails` field. [#the-dbs-singapore-payment-api-now-accepts-an-optional-paymentdetails-field]

* For ACT, MEPS, and TT, `paymentDetails` is sent to the beneficiary bank. It is also included in the email advice when an advice email is provided.
* For FAST and PAYNOW, `paymentDetails` is not sent to the beneficiary bank. It is included in the email advice only when an advice email is provided.

#### We corrected and clarified the DBS Singapore API payment rules to match Acme's validation. The validation behavior is unchanged. These updates correct the documentation. [#we-corrected-and-clarified-the-dbs-singapore-api-payment-rules-to-match-acmes-validation-the-validation-behavior-is-unchanged-these-updates-correct-the-documentation]

* FAST/PAYNOW `receiver.name` charset is `G_I3` up to 140 characters. It was previously stated as SWIFT.
* ACT `receiver.name` charset on the V4 API is `SWIFT` up to 35 characters. It was previously stated as G\_I3.
* We noted that `receiver.name` for FAST, PAYNOW, and the V4 tables is validated by DBS, not by Acme upfront.

#### Link to updated payment rules: [#link-to-updated-payment-rules-1]

* [Acme DBS Singapore Payments (API)](/guides/dbs-sg-api-payments)

***

### Enhancement: DBS Singapore H2H Updates [#enhancement-dbs-singapore-h2h-updates]

#### The DBS Singapore H2H advice email and DBS IDEAL display now source the Invoice Details field from `paymentDetails`. [#the-dbs-singapore-h2h-advice-email-and-dbs-ideal-display-now-source-the-invoice-details-field-from-paymentdetails]

* `paymentDetails` now populates the **Invoice Details** field in the advice email.
* `customerReference` now populates the **Client Reference** field in the advice email.
* If `paymentDetails` is not provided, Acme uses `customerReference` as the **Invoice Details** so the field is never empty.
* This applies to all H2H payment types when advice emails are provided in `paymentAdviceEmails` for the payment.

#### We corrected the existing DBS Singapore H2H payment rules to match Acme's validation. This is a documentation change only and does not change behavior. [#we-corrected-the-existing-dbs-singapore-h2h-payment-rules-to-match-acmes-validation-this-is-a-documentation-change-only-and-does-not-change-behavior]

* `receiver.address` is a structured object with the fields `line1`, `line2`, `city`, `state`, `postalCode`, and `country`. Acme flattens these into **3 lines of up to 35 SWIFT characters** before submission.
* The address packing applies to every existing payment type that accepts an address (FAST, PAYNOW, PAYNOW\_GIRO, GIRO, MEPS, TT).
* `line1` is mandatory only for **MEPS** and **TT**. It is optional for the other types.
* The MEPS and TT tables previously inaccurately documented the address as a single mandatory `line1` of 35 characters.
* `receiver.bankAccountNumber` is **alphanumeric** for FAST, GIRO, and ACT. It allows alphanumeric plus the hyphen character for MEPS and TT. It was previously stated as numeric.
* We documented the existing optional fields `receiver.intermediaryBank` (MEPS, TT) and `receiver.localRoutingIdentifier` (TT).

#### Link to updated payment rules: [#link-to-updated-payment-rules-2]

* [Acme DBS Singapore Payments (H2H)](/guides/dbs-sg-payments)

***

## Jun 11, 2026 [#jun-11-2026]

### Enhancement: Zand Bank UAE — Improved Transaction Types Categorization [#enhancement-zand-bank-uae--improved-transaction-types-categorization]

* Improved `transactionType` categorization in [Transactions API](/reference/get-transactions) for Zand Bank UAE transactions, aligned with the [Zand payment types](/guides/zand-ae-payments).
* Removed domestic transactions with inaccurate `transactionType` : `ACH`, `RTP`.

#### Link to Zand Bank Transaction Types Categorization: [#link-to-zand-bank-transaction-types-categorization]

* [Acme Zand Bank UAE Transactions](/guides/zand-ae-transactions)

***

## Jun 5, 2026 [#jun-5-2026]

### Upcoming Change: DBS Singapore — SWIFT ISO 20022 CBPR+ and HVPS+ migration (API and H2H) [#upcoming-change-dbs-singapore--swift-iso-20022-cbpr-and-hvps-migration-api-and-h2h]

As part of Acme's migration across all banking partners to comply with **ISO 20022 CBPR+ and HVPS+** requirements ahead of the **SWIFT November 2026 deadline**, the **DBS Singapore** payment rules will change across both the **API** and **H2H** integrations.

Acme will be migrating to the new DBS endpoints and file format once clients are ready. In the meantime, clients should **start updating their integrations now** — particularly to populate the newly **required** fields and sanitize values that fall outside the new character sets — so that payments continue to be accepted after the cutover.

#### Summary of change: [#summary-of-change]

**DBS Singapore H2H** (MEPS, TT, ACT):

* `receiver.name` max length increased from **35 → 140** across MEPS, TT, and ACT.
* MEPS and TT: `receiver.address.city` and `receiver.address.country` are now **required**. `receiver.address.line1` and `line2` max length increases to **70**; `state` and `postalCode` remain optional.
* New `outgoingPurposeCode` field for **TT** — **mandatory** when the payment currency is `MYR`, `CNH`/`CNY`, `INR`, or `KWD`, or when the beneficiary country is **Myanmar (`MM`)** or **United Arab Emirates (`AE`)**. Partners should obtain the applicable purpose code list from DBS or refer to the destination country's regulator.

**DBS Singapore API** (ACT):

* `receiver.name` max length increased from **35 → 140**.
* **Breaking change**: `receiver.name` charset is restricted from `G_I3` → `SWIFT`. Existing payee names containing characters outside the SWIFT character set (e.g. `!`, `#`, `$`, `%`, `&`, `*`, `;`, `=`, `@`, `[`, `]`, `^`, `_`, `` ` ``, `{`, `}`, `|`, `~`) will be **rejected**. Clients must sanitize stored payee names before migrating.

#### Link to updated payment rules: [#link-to-updated-payment-rules-3]

* [Acme DBS Singapore Payments (H2H)](/guides/dbs-sg-payments)
* [Acme DBS Singapore Payments (API)](/guides/dbs-sg-api-payments)