Add Swift BIC Code to Get Payees and Get Scheduled Payments API

[jankrishnan]

Description

We would like to submit a change request for Get Payee Detail and Get Scheduled Payments set. The reason for this change is because SWIFT BIC is widely used amongst domestic accounts. HSBCnet is a global platform that links together all of the customers accounts held with the HSBC bank globally so using the SWIFT BIC enables us to route those internal transfers globally.

To ensure our global network can communicate effectively we would like to keep that mapping in place and use that within the get schedule payee detail and schedule payment details.

Area Affected

The fields are located in BankingPayeeDetailV2.domestic.account and BankingScheduledPaymentTo.BankingDomesticPayee.account object.

Please see below before and after the change :

Change Proposed

Before

1. accountName (optional)
2. bsb (mandatory)
3. accountNumber (mandatory)

After

1. accountName (optional)
2. bsb (optional)
3. accountNumber (optional)
4. swiftBIC (optional)

[markskript]

We would suggest that making the BSB and Account Number fields conditional would be better, otherwise 'technically' the ADH could provide none of those fields. We suggest the following change.

Proposed change:

1. accountName (optional)
2. bsb (conditional - optional only if swiftBIC is provided, otherwise mandatory)
3. accountNumber (conditional - optional only if swiftBIC is provided, otherwise mandatory)
4. swiftBIC (optional)

[jankrishnan]

Hi Mark, I agree with your suggestion below. Thank you. Regards, Janice From: Mark Wallis ***@***.***> Sent: Sunday, 16 July 2023 11:20 AM To: ConsumerDataStandardsAustralia/standards-maintenance ***@***.***> Cc: Janice KRISHNAN ***@***.***>; Author ***@***.***> Subject: EXTERNAL: Re: [ConsumerDataStandardsAustralia/standards-maintenance] Add Swift BIC Code to Get Payees and Get Scheduled Payments API (Issue #596) We would suggest that making the BSB and Account Number fields conditional would be better, otherwise 'technically' the ADH could provide none of those fields. We suggest the following change. Proposed change: accountName (optional) bsb (conditional ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organisation. The content & any attachments need to be treated with care and attention. ZjQcmQRYFpfptBannerEnd We would suggest that making the BSB and Account Number fields conditional would be better, otherwise 'technically' the ADH could provide none of those fields. We suggest the following change. Proposed change: accountName (optional) bsb (conditional - optional only if swiftBIC is provided, otherwise mandatory) accountNumber (conditional - optional only if swiftBIC is provided, otherwise mandatory) swiftBIC (optional) - Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/596*issuecomment-1636940008__;Iw!!LSAcJDlP!1Tu3ybwRhivuRkbxuiXc0l-de_dZ4Evnb7vbZV4lvTKQDiv3Rh7UpucI3L0IABX9sFvBGJjTjM8EHVLIXfuyQN9IHaihoQ$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/A6PF3WADZQICVDDEEIKK6U3XQM6VBANCNFSM6AAAAAAZMYBS74__;!!LSAcJDlP!1Tu3ybwRhivuRkbxuiXc0l-de_dZ4Evnb7vbZV4lvTKQDiv3Rh7UpucI3L0IABX9sFvBGJjTjM8EHVLIXfuyQN_jWL8C1w$>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

…

________________________________

________________________________ ****************************************************************** This message originated from the Internet. Its originator may or may not be who they claim to be and the information contained in the message and any attachments may or may not be accurate. ****************************************************************** INTERNAL ******************************************************************* This e-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. ******************************************************************* "SAVE PAPER - THINK BEFORE YOU PRINT!"

[CDR-API-Stream]

@jankrishnan has requested this comment/ question to be added. While they fix issues with their GitHub account.

“Can we use toUType of ‘domestic’ in conjunction with BankingInternationalPayee object ? If so, then that will allow us to share the BIC code for domestic payments”

[nils-work]

Hi @jankrishnan

The payeeUType description states 'Type of object included that describes the payee in detail'.
If you specify domestic but provide an international object (or even both), it may be unlikely that recipients would refer to the international data (and may not store it), and they may consider this scenario a schema error as the fields are conditional.

If your system stores domestic payee details in an international format, they could be shared by either specifying the international payeeUType, or they could be converted and shared as the domestic format if you are able to do so. A consideration may be whether your customers are aware that their domestic payees are specified using the international format, or whether this is only an internal process for routing efficiency. How this data may be interpreted by data recipients (which may be other domestic banks) may also be a consideration.

[jankrishnan]

Hi Nils, In the previous meeting, someone from your team (can't remember the name) recommended that we use 'domestic' as the payeeUType together with the international object. Seems like this advise has changed ? Our system classifies these payees as domestic because it's used by customers to do domestic interbank transfers. Classifying domestic payees as international will confuse our customers as well as their ADRs. If the previous advise has changed, then can we please go back to our original request which is to add a swift BIC field for the domestic object ? Regards Janice From: Nils Berge ***@***.***> Sent: Monday, 7 August 2023 5:31 PM To: ConsumerDataStandardsAustralia/standards-maintenance ***@***.***> Cc: Janice KRISHNAN ***@***.***>; Mention ***@***.***> Subject: EXTERNAL: Re: [ConsumerDataStandardsAustralia/standards-maintenance] Add Swift BIC Code to Get Payees and Get Scheduled Payments API (Issue #596) Hi @jankrishnan The payeeUType description states 'Type of object included that describes the payee in detail'. If you specify domestic but provide an international object (or even both), it may be unlikely that recipients would refer to the ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organisation. The content & any attachments need to be treated with care and attention. ZjQcmQRYFpfptBannerEnd Hi @jankrishnan<https://urldefense.com/v3/__https:/github.com/jankrishnan__;!!LSAcJDlP!20jkZFdRrcCWSWX9D7xD2aJv-NU-SqzP8Q9rbQblkLSs3F_nBUZj7j0a6juDlpySaB66isW1w0JRnAGxemH7Pi5CpfJrRg$> The payeeUType description states 'Type of object included that describes the payee in detail'. If you specify domestic but provide an international object (or even both), it may be unlikely that recipients would refer to the international data (and may not store it), and they may consider this scenario a schema error as the fields are conditional. If your system stores domestic payee details in an international format, they could be shared by either specifying the international payeeUType, or they could be converted and shared as the domestic format if you are able to do so. A consideration may be whether your customers are aware that their domestic payees are specified using the international format, or whether this is only an internal process for routing efficiency. How this data may be interpreted by data recipients (which may be other domestic banks) may also be a consideration. - Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/596*issuecomment-1667338128__;Iw!!LSAcJDlP!20jkZFdRrcCWSWX9D7xD2aJv-NU-SqzP8Q9rbQblkLSs3F_nBUZj7j0a6juDlpySaB66isW1w0JRnAGxemH7Pi5CfurqJQ$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/A6PF3WFU4OMMA3TF6IRC5CTXUCKTPANCNFSM6AAAAAAZMYBS74__;!!LSAcJDlP!20jkZFdRrcCWSWX9D7xD2aJv-NU-SqzP8Q9rbQblkLSs3F_nBUZj7j0a6juDlpySaB66isW1w0JRnAGxemH7Pi6RLE3_TA$>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

…

________________________________

________________________________ ****************************************************************** This message originated from the Internet. Its originator may or may not be who they claim to be and the information contained in the message and any attachments may or may not be accurate. ****************************************************************** PUBLIC ******************************************************************* This e-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. ******************************************************************* "SAVE PAPER - THINK BEFORE YOU PRINT!"

[nils-work]

Hi @jankrishnan

The comment from the previous meeting was that there is nothing in the Standards to suggest that what a consumer may consider a 'domestic' payee or scheduled payment can only be defined using domestic details.

It was stated that while it may be unusual, what could be considered a 'domestic' payment can be defined using the international format, by specifying AUS as the country and so on, but the toUType or payeeUType should always correspond to the schema being provided.

It was also noted that an account number would still be expected to be mandatory if beneficiaryBankBIC code was to added to the domestic schema.

[jankrishnan]

Thanks Nils. We will adopt this and happy for the previously requested changes to be dropped. From: Nils Berge ***@***.***> Sent: Tuesday, 8 August 2023 4:24 PM To: ConsumerDataStandardsAustralia/standards-maintenance ***@***.***> Cc: Janice KRISHNAN ***@***.***>; Mention ***@***.***> Subject: EXTERNAL: Re: [ConsumerDataStandardsAustralia/standards-maintenance] Add Swift BIC Code to Get Payees and Get Scheduled Payments API (Issue #596) Hi @jankrishnan The comment from the previous meeting was that there is nothing in the Standards to suggest that what a consumer may consider a 'domestic' payee or scheduled payment can only be defined using domestic details. It was stated ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organisation. The content & any attachments need to be treated with care and attention. ZjQcmQRYFpfptBannerEnd Hi @jankrishnan<https://urldefense.com/v3/__https:/github.com/jankrishnan__;!!LSAcJDlP!z1qfFAJPbfVmpTIVkOSS742lr9QUp4Nlk-GUp7VgQDH0fd9O6kCKkprBnTCmHE-Ro9f5t5p3iD9eY3xKWZTZ4swVM2d53A$> The comment from the previous meeting was that there is nothing in the Standards to suggest that what a consumer may consider a 'domestic' payee or scheduled payment can only be defined using domestic details. It was stated that while it may be unusual, what could be considered a 'domestic' payment can be defined using the international format, by specifying AUS as the country and so on, but the toUType or payeeUType should always correspond to the schema being provided. It was also noted that an account number would still be expected to be mandatory if beneficiaryBankBIC code was to added to the domestic schema. - Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/596*issuecomment-1668979456__;Iw!!LSAcJDlP!z1qfFAJPbfVmpTIVkOSS742lr9QUp4Nlk-GUp7VgQDH0fd9O6kCKkprBnTCmHE-Ro9f5t5p3iD9eY3xKWZTZ4szpJtocSg$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/A6PF3WEGOIT5APQJ6GLBSITXUHLPFANCNFSM6AAAAAAZMYBS74__;!!LSAcJDlP!z1qfFAJPbfVmpTIVkOSS742lr9QUp4Nlk-GUp7VgQDH0fd9O6kCKkprBnTCmHE-Ro9f5t5p3iD9eY3xKWZTZ4swGT9pdIA$>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

…

________________________________

________________________________ ****************************************************************** This message originated from the Internet. Its originator may or may not be who they claim to be and the information contained in the message and any attachments may or may not be accurate. ****************************************************************** PUBLIC ******************************************************************* This e-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. ******************************************************************* "SAVE PAPER - THINK BEFORE YOU PRINT!"

[nils-work]

Hi @jankrishnan
Closing this issue per your response. Thanks