Notice of Change

This page lists important service-level changes that may impact your integration with LHV Connect. Each notice includes a summary of what’s changing, who it affects, and any required actions.

Notices are listed in reverse chronological order, with the newest changes at the top.

For assistance with updates or other aspects of the Connect API, please contact [email protected].

---

📣 New Payment Scheme Code – Payments Between Customer’s Own Accounts

Issued: 6 January 2026 Production Release: 25 February 2026

Overview

LHV is introducing a new payment scheme code to clearly identify payments made between a customer’s own accounts. This enhancement improves user experience, transparency for integrators, ensures more accurate reporting, and aligns all channels with a consistent payment classification model.

What Is a Payment Between Own Accounts?

A payment between own accounts is a type of internal payment where:

The transfer is made between two accounts belonging to the same customer within LHV Bank.

New payment scheme code: BETWEEN_OWN

Automatic assignment The Between Own Accounts payment scheme is not selectable by the customer and is automatically assigned when both accounts belong to the same customer.

This new classification will appear in both API interactions and Customer Portal.

Where the Payment Scheme Code Appears

BETWEEN_OWN will appear in Payment Scheme Codes here: Payment Scheme Codes | Connect | Documentation for LHV CONNECT

The code will be included in all standard message formats and account reporting files:

Message/File	Description	Message element
pain.002	The payment scheme associated with payment processing will reflect the new type when applicable	/.../TxInfAndSts/OrgnlTxRef/PmtTpInf/SvcLvl/Prtry <PmtTpInf> <SvcLvl> <Prtry>BETWEEN_OWN</Prtry> </SvcLvl> </PmtTpInf>
camt.054	Transaction notifications will reflect the new type when applicable	/.../Ntry/BkTxCd/Prtry/Cd <BkTxCd> <Prtry> <Cd>BETWEEN_OWN</Cd> </Prtry> </BkTxCd>
camt.053	Account statements will reflect the new type when applicable	/.../Ntry/BkTxCd/Prtry/Cd <BkTxCd> <Prtry> <Cd>BETWEEN_OWN</Cd> </Prtry> </BkTxCd>
Account Statement XML (Customer Portal)	Payment scheme type visible for relevant transactions

What you need to do?

No action is required if your systems already support unknown or new payment scheme values.

However, customers should review the following areas to ensure smooth adoption:

• Validation logic If your system validates payment scheme values against a fixed list, please add support for the new value BETWEEN_OWN.

• Message parsing Ensure your integrations can correctly parse the new value in payment and account reporting messages, including:

  • pain.002

  • camt.053 and camt.054

• Reporting and categorisation If you group, filter, or label transactions by payment type, consider whether Between Own Accounts should be handled or displayed differently.

---

Previous notices:

Response Compression in Connect API

📣 Response Compression in Connect API

Issued: 22 April 2025 Original Production Release: 26 May 2025 Updated: 28 May 2025 New Production Release: 9 June 2025

The roll out of the response compression change has been delayed to give customers more time to prepare. The new production release date is: 9 June 2025

What’s Changing and Why

LHV Connect is introducing response compression for large API responses to improve performance and transmission efficiency. Compression applies to payloads ≥10MB and helps reduce bandwidth usage, especially for endpoints that return large message bodies (e.g., Get next message). Most modern HTTP clients support decompression automatically, but behavior may vary depending on the tools or libraries used.

This change is currently available in Prelive environment and is scheduled for Production rollout on 9 June 2025 (previously planned for 26 May 2025).

Does This Affect You?

This change may impact you if:

• You use the UK Connect API: https://connect.lhv.com (Clients using https://connect.lhv.eu are not affected)

• You use Connect’s Message Services, such as GET /messages/next

• You expect to receive API responses ≥10MB

• Your HTTP client does not support response decompression or lacks a compatible Accept-Encoding header

If a compressed response is triggered but your client cannot decompress it, the API may return an error (e.g., HTTP 500). Currently, the most likely affected service is Account Statement delivery.

What You Need to Do

To ensure compatibility:

• Add the Accept-Encoding header to your requests: gzip, deflate, or both

• Confirm that your HTTP client supports decompression (most modern libraries do this by default)

Compression will only be applied if:

• The response body is at least 10MB, and

• The request includes a supported Accept-Encoding header

Now we have also available a dedicated service for quick and easy testing of Compression. More details at Get compressed message for testing

Additional Information and Resources

• For more details see Response Compression