> For the complete documentation index, see [llms.txt](https://docs.lhv.com/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lhv.com/home/connect/news-and-updates/notice-of-change.md).

# 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 %}

***

### Upcoming Change: Removal of Unstructured Address

Issued: **13 May 2026**\
Sandbox Release: **July 2026**\
Production Release: **November 2026**

#### Background

The removal of unstructured postal addresses in payments is a global, industry-wide change aimed at improving data quality, transparency and screening efficiency.

This change is aligned across:

* SWIFT cross-border payments (CBPR+) and high-value payment systems (HVPS+, including CHAPS in UK)
* SEPA Credit Transfer (SCT) and SEPA Instant Credit Transfer (SCT Inst), and SEPA

As part of this evolution, the use of fully unstructured postal addresses (i.e. only \<AdrLine> elements) will be discontinued.

Customers must ensure that address information is provided in either:

* **Hybrid format**, or
* **Fully structured format (recommended)**

Relevant industry references:

* SWIFT CBPR+: <https://www.swift.com/standards/iso-20022/removal-unstructured-address>
* EPC (SEPA): <https://www.europeanpaymentscouncil.eu/document-library/guidance-documents/epc-guidance-document-provision-addresses-under-epc-payment>
* Bank of England (CHAPS): <https://www.bankofengland.co.uk/paper/2024/policy-statement/mandating-iso-20022-enhanced-data-in-chaps>

#### **Scope**

This requirement applies to all parties in the payment message **pain.001.001.09** where the Postal Address element \<PstlAdr> is used, including:

* Debtor
* Creditor
* Ultimate Debtor (if present)
* Ultimate Creditor (if present)
* Etc

Schema files will not be affected by this change.

#### **Timeline**

Customers must implement the required changes **by 14 November 2026 at the latest**. When sending payments with value date of 14th of November or greater, it must be accompanied with hybrid or structured address data.

From this date, payments containing fully unstructured addresses may be rejected by payment schemes or intermediary banks.

LHV already supports both hybrid and fully structured address formats. Customers are strongly advised to adopt the new formats as early as possible and not wait until the deadline.

#### **Hybrid Format**

The hybrid format combines structured and unstructured elements.

**Minimum required structured elements:**

* \<TwnNm> (Town Name)
* \<Ctry> (Country)

Additionally:

* Up to **2 occurrences of** \<AdrLine> are permitted
* Each \<AdrLine> may contain up to **70 characters**

Example:

```
<PstlAdr>
    <TwnNm>Milano</TwnNm>
    <Ctry>IT</Ctry>
    <AdrLine>Via Roma 42, 20121</AdrLine>
</PstlAdr>
```

Other structured elements (e.g. \<StrtNm>, \<BldgNb>, \<PstCd>) may also be included in hybrid format.

#### **Fully Structured Format (Recommended)**

The structured format uses only structured address elements and is strongly recommended.

**Minimum required elements:**

* \<TwnNm> (Town Name)
* \<Ctry> (Country)

Example:

```
<PstlAdr>
    <StrtNm>Via Roma</StrtNm>
    <BldgNb>42</BldgNb>
    <PstCd>20121</PstCd>
    <TwnNm>Milano</TwnNm>
    <Ctry>IT</Ctry>
</PstlAdr>
```

#### **Testing in LHV Connect**

LHV provides customers with the possibility to test pain.001 files using future validation rules.

This can be done by including a specific value ‘FUTURE:RULE:ADDR\_STRUCT’ in the unstructured remittance information field (\<Ustrd>). When this value is present, the payment will be validated according to the future address requirements. Functionality will be available from July 2026.

Customers are encouraged to use this functionality to validate their files and ensure readiness ahead of the November 2026 deadline.

***

### Upcoming Change: New CAMT Message Versions for Account Information Services

Issued: **13 May 2026**\
Sandbox Release: **July 2026**

#### **Overview**

Introducing new CAMT message versions for Account Information Services in preparation for the November 2026 industry deadline related to structured address support in payment schemes.

The following message versions will be introduced:

* `camt.060.001.03` -> `camt.060.001.05`
* `camt.052.001.06` -> `camt.052.001.08`
* `camt.053.001.02` -> `camt.053.001.08`
* `camt.054.001.02` -> `camt.054.001.08`

Existing and new CAMT versions will be supported in parallel for a transition period.

The current CAMT versions do not contain the elements required to support structured address information and will not be updated for this purpose.

#### **What You Need to Do**

No immediate action is required.

Clients should review whether their systems support the new CAMT versions and plan migration ahead of the November 2026 deadline where structured address support is required.

More detailed information about implementation timelines, migration options, and testing will be provided separately.

***

### 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](/home/connect/services/messages/get-next-message.md)).\
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](/home/connect/services/account-reports/account-statement.md) 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 compressed message for testing](/home/connect/services/messages/get-next-message-1.md)
{% endhint %}

#### Additional Information and Resources

* For more details see [Response Compression](/home/connect/fundamentals/response-compression.md)

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.lhv.com/home/connect/news-and-updates/notice-of-change.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.