AIS - New Account Type Field

[chatelao]

Proposal:

• https://open-banking.pass-consulting.com/json_ExternalCashAccountType1Code.html

This language independant code list (CashAccountType from ISO20022) is an idea to be used as a formal list of account type to be normalized over all banks.

[simonmeyerm]

SIX agrees to implement this field to specify the account type.

The new field should be mandatory and expect either

• An enum with all values of the ExternalCashAccountType1Codes or
• A string with "maxLength: 4" in order to be flexible in case of changes of account types

Additional Questions: What happens with the field designation in the AccountInformationItem? This field could be renamed to rubric or remain as designation, but further defined that a rubric is expected.

[svenbiellmann]

Needs to be discussed together with #28

[svenbiellmann]

Relates to issue no. 16 in the SIX Orchestration Project «Multibanking for Individuals»

[RaulGuirao]

The results of the first analysis were summarized in the attached document.

On the SFTI meeting on 2nd November following questions need to be discussed and clarified: A) What is the added value of the standardized account type list? Which use case will be supported? B) Which is the preferred option: standardized code list or bank specific account type category? C) Will the banks be able to provide the information? What is the estimated effort for each option in question B. SFTI XS2A_GitHub Number 61_Account Type_2023-11_V0-1.pdf

[svenbiellmann]

Meeting Notes 2.11.23

It was confirmed that Service User will be able to sort out and filter accounts according to the account type information and so provide an added value and enable different use cases.

The preference is a standardized category account list. Therefore, the efficient way is to leverage in XML / camt the ISO code list with 23 entries and the element Account/Type/Code. This data in this element is mandatorily to be provided. 

It is key that the banks will be able to support it accurately and provide the proper code of the account. It was agreed that the Service Provider shall investigate on feasibility for implementation of this element with code list. 

Action Point:  @ Service Provider: Check feasibility for implementation of element with code list in XML / camt and JSON. Is an implementation for JSON in Autumn 2024 (V4) possible?

[RaulGuirao]

Due to to different challenges with respect to usage of the ISO list with the 23 types, such as

• possible mapping of the bank account to more than one account type
• many types are not useful or applicable for our Multibanking case
• a few types may be interpreted unequally by the banks and may lead to inconsistent mapping among the banks a proposal was prepared to reduce the type list and provide guidance by specifying the content:

The table of the reduced types is attached on the file SFTI XS2A_GitHub Number 61_Account Type_2023-11_V2-0.pdf on page 4 at the topic "agreed moving forward". SFTI XS2A_GitHub Number 61_Account Type_2023-11_V2-0.pdf

[svenbiellmann]

Meeting Notes 7.12.23

It was agreed that all values of ISO External Cash Account Type list can be used. There will be no technical restriction. It was further agreed that a strong recommendation will help on consistent interbank mapping and usage. Therefore it is recommended to use the codes / types as follows:

Specially in the Retail Multibanking the mostly relevant codes are LAON, LLSV, SVGS and TRAN.

The proposal is to implement this new element in the V4 temporally as optional and then set it up mandatory with V5 (November 2025). The array of codes will be set up as enum (array) and exclusively allow the predefined ISO codes.

In XML / camt this element (Account/Name/Type/Code) can already be used in the present. In the SIX ISO working group the change needs to be requested as to document this element in the SPS Implementation Guides as mandatory from November 2025 on.