# 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.

{% hint style="info" %}
For assistance with updates or other aspects of the Connect API, please contact <operations@lhv.com>.
{% endhint %}

***

***

### Previous notices:

<details>

<summary>New Payment Scheme Code – Payments Between Customer’s Own Accounts</summary>

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

Issued: **6 January 2026**\
Production Release: **25 February 2026**

#### **Overview** <a href="#overview" id="overview"></a>

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 href="#what-is-a-payment-between-own-accounts" id="what-is-a-payment-between-own-accounts"></a>

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** <a href="#where-the-new-interface-type-appears" id="where-the-new-interface-type-appears"></a>

`BETWEEN_OWN` will appear in Payment Scheme Codes here: [Payment Scheme Codes | Connect | Documentation for LHV CONNECT](https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-schemes)

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

<table><thead><tr><th width="227.7109375">Message/File</th><th width="260">Description</th><th>Message element</th></tr></thead><tbody><tr><td><strong>pain.002</strong></td><td>The payment scheme associated with payment processing will reflect the new type when applicable</td><td><p></p><p>/.../TxInfAndSts/OrgnlTxRef/PmtTpInf/SvcLvl/Prtry</p><pre class="language-xml"><code class="lang-xml">&#x3C;PmtTpInf>
  &#x3C;SvcLvl>
    &#x3C;Prtry>BETWEEN_OWN&#x3C;/Prtry>
  &#x3C;/SvcLvl>
&#x3C;/PmtTpInf>
</code></pre></td></tr><tr><td><strong>camt.054</strong></td><td>Transaction notifications will reflect the new type when applicable</td><td><p>/.../Ntry/BkTxCd/Prtry/Cd</p><pre class="language-xml"><code class="lang-xml">&#x3C;BkTxCd>
  &#x3C;Prtry>
    &#x3C;Cd>BETWEEN_OWN&#x3C;/Cd>
  &#x3C;/Prtry>
 &#x3C;/BkTxCd>
</code></pre></td></tr><tr><td><strong>camt.053</strong></td><td>Account statements will reflect the new type when applicable</td><td><p>/.../Ntry/BkTxCd/Prtry/Cd</p><pre class="language-xml"><code class="lang-xml">&#x3C;BkTxCd>
  &#x3C;Prtry>
    &#x3C;Cd>BETWEEN_OWN&#x3C;/Cd>
  &#x3C;/Prtry>
&#x3C;/BkTxCd>
</code></pre></td></tr><tr><td><strong>Account Statement XML (Customer Portal)</strong></td><td>Payment scheme type visible for relevant transactions</td><td> </td></tr></tbody></table>

### What you need to do? <a href="#what-you-need-to-do" id="what-you-need-to-do"></a>

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.

</details>

<details>

<summary>Response Compression in Connect API</summary>

### 📣 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**

{% hint style="danger" %}
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**
{% endhint %}

#### 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](https://docs.lhv.com/home/connect/services/messages/get-next-message "mention")).\
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`\
  \&#xNAN;*(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](https://docs.lhv.com/home/connect/services/account-reports/account-statement "mention") 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

{% hint style="warning" %}
Now we have also available a dedicated service for quick and easy testing of Compression. More details at [get-next-message-1](https://docs.lhv.com/home/connect/services/messages/get-next-message-1 "mention")
{% endhint %}

#### Additional Information and Resources

* For more details see [response-compression](https://docs.lhv.com/home/connect/fundamentals/response-compression "mention")

</details>