Define new toUType value to relevant schemas

[PayPalAustralia]

Description

PayPal Australia Pty Limited (PayPal) is a limited Authorised Deposit-Taking Institution with authority to provide purchase payment facilities. Its primary business is as a digital wallet provider that allows buyers and sellers to send and receive payments online. PayPal customers are able to store balance in their PayPal account and withdraw those funds to a linked bank account, pay for goods and services or make person to person transactions within PayPal’s closed network using their PayPal account. There are three (3) types of accounts offered by PayPal: a Personal Account, a Premier Account (no longer available to new customers) and a Business Account.

As previously set out in the change request that PayPal raised in July 2021 (Define new Payee Type Digital Wallet Payee Type to relevant schemas #396) (“Change Request 396”), PayPal does not offer traditional banking products and its business and operational models are different to that of a traditional bank. Change Request 396 established a new Payee schema type of “DIGITAL_WALLET” and a payeeUType of digitalWallet, which will become mandatory on 31 August 2022. The scope of Change Request 396 did not address the ‘toUType’ field within the BankingScheduledPaymentTo schema and as such PayPal is currently unable to return information about the payee of a scheduled payment.

It is also worth noting that unlike a traditional bank, scheduled payments on a Digital Wallet do not need to be made to a pre-registered Payee.

Area Affected

To ensure PayPal data is accurately reflected and returned in the Australian Consumer Data Right ecosystem, we are recommending the following changes be made to the BankingScheduledPaymentTo schema, which is utilised by the following APIs:
• Get Scheduled Payments for Account
• Get Scheduled Payments Bulk
• Get Scheduled Payments by Specific Accounts API

BankingScheduledPaymentTo schema (https://consumerdatastandardsaustralia.github.io/standards/#tocSbankingscheduledpaymentto)
BankingScheduledPayment --> BankingScheduledPaymentSet --> BankingScheduledPaymentTo --> toUType

Current Enum Values for BankingScheduledPaymentTo.toUType:

   accountId
   PayPal cannot utilise this value, as Scheduled Payments are not to accounts owned by the consumer, and hence are not accessible under the current consent.

   biller
   PayPal cannot utilise this value, as we do not support any payments (including Scheduled Payments) to a BPAY biller. 

   domestic
   PayPal cannot utilise this value, as we do not support Scheduled Payments to a domestic bank account. 

   international
   PayPal cannot utilise this value, as we do not support Scheduled Payments to an international bank account 

   payeeId
   PayPal cannot utilise this value.  As noted above, the recipient of Scheduled Payments is not a pre-registered payee that would be included in the Payee scope.

Change Proposed

To ensure PayPal can comply with the regulatory mandates, we would like to put forth the following two changes to the BankingScheduledPaymentTo API response schema:

Change#1
Add a new Enumerated Value to the toUType field in the BankingScheduledPaymentTo response schema. PayPal recommends
this value to be:
Property: toUType
Value: digitalWalletPayee

Change#2
To support the addition of the new toUType Enumerated Value referenced in Change #1, there are two options that PayPal
would support. Of the two options, PayPal recommends Option 1.
Option 1:
To support the new Enumerated value described in the Change #1, add a new Properties field in the
BankingScheduledPaymentsTo response schema to reference the BankingDigitalWalletPayee schema created with Change
Request #396. PayPal recommends this field to be:
Name: digitalWalletPayee
Type: schema BankingDigitalWalletPayee (existing payeeUType
https://consumerdatastandardsaustralia.github.io/standards/#tocSbankingdigitalwalletpayee)
Required: Conditional
Description: Present if toUType is set to digitalWalletPayee
Option 2:
To support the new Enumerated value described in the Change #1, add a new Properties field in the
BankingScheduledPaymentsTo response schema. PayPal recommends this field to be:
Name: digitalWalletPayee
Type: ASCIIString
Required: Conditional
Description: Present if toUType is set to digitalWalletPayee. Represents the merchant/payee ID of the recipient of the
Scheduled Payment and could be used by the ADR within the Get Payee Detail API to retrieve the payee
information. It is important to note that this payee would not be automatically returned in the Get Payees
API in the event that Payees are within the scope of the consent.

[nils-work]

For Change#1, I would suggest the toUType enum value and corresponding property name be digitalWallet to align to the related name in BankingPayeeDetailV2 (the schema name is BankingDigitalWalletPayee).

I believe Option 1 of Change#2, incorporating the full associated schema, would be better aligned to the addition of the new toUType proposed in Change#1.
That approach would seem to be:

• be more consistent with the related payeeUType convention in BankingPayeeDetailV2,
• be more consistent with the toUType for domestic, international and payeeId in BankingScheduledPaymentTo and other areas of the Standards,
• provide flexibility for different digital wallet identifier and provider values through the associated BankingDigitalWalletPayee schema, and
• avoid the scenario described in Option#2 where a corresponding payee ID may not be available in the Get Payee Detail endpoint. This would result in the Payee detail remaining unknown.

I would also suggest that this is actually only a single change to add the digitalWallet uType and its associated schema to BankingScheduledPaymentTo, but welcome any other comments or preferences.

It appears that Option#2 may be duplicating the purpose of the existing payeeId field in BankingScheduledPaymentTo, where a 'payeeId' (as an ID Permanence value) is provided for querying the Get Payee Detail endpoint.

Also to note, this appears to be the only change in the maintenance backlog related to the Scheduled Payments endpoints.

[biza-io]

Supporting digital wallet targets for schedule payments to align with payees makes sense. Our thoughts as to a way forward are that it probably shouldn’t be assumed that a payee is registered for a scheduled payment. That is to say that expecting the presence of payeeId may result in certain use cases not being possible.

On this basis our suggestion would be to adopt a structure similar to BankingDigitalWalletPayee (id, type, provider) with an additional uType as suggested.

[perlboy]

Indication was given at the last MI call this has been staged? We can find the branch here https://github.com/ConsumerDataStandardsAustralia/standards-staging/compare/maintenance/536 but we are unable to determine what branch it should be compared against?

[nils-work]

Hi @perlboy
I believe it's this one - ConsumerDataStandardsAustralia/standards-staging@release/1.24.0...maintenance/536

[benkolera]

Just noticing that we (Biza.io) forgot to submit a bit of feedback on this one:

The reuse of the BankingDigitalWalletPayee means that it is not possible to specify the name as the sender of the payment may not know the name assigned by the receivers account or the digital wallet provider. Our suggestion would be to define a specific payload for scheduled digital wallet payments which does not include name but continues to include identifier, type and provider.

Additionally, as this is the introduction of an additional uType it would appear this should increment the version number of the endpoint.

[nils-work]

Hi @benkolera

Incrementing the endpoint version for this change has been noted, thanks.

This change will result in version 2 of these Banking endpoints:

• Get Scheduled Payments for Account
• Get Scheduled Payments Bulk
• Get Scheduled Payments For Specific Accounts

A Future Dated Obligation for version 2 will be proposed as Y24 #1 - 11/03/2024, with the retirement date for version 1 as Y24 #4 - 09/09/2024. If there are concerns with these dates they can be discussed in a future Maintenance Iteration.

To clarify the name field, a change to the description will be proposed, from:

The name assigned to the digital wallet by the owner of the wallet, else the display name provided by the digital wallet provider

To:

The display name of the wallet as given by the customer, else a default value defined by the data holder

This is not intended to be a change in meaning and is not considered a breaking change. It would apply to the corresponding description in the following schemas:

• BankingScheduledPaymentTo (where it is being introduced by this issue)
• TelcoPaymentScheduleDigitalWallet
• BankingDigitalWalletPayee
• EnergyPaymentSchedule

[perlboy]

Just noticed this but:

The display name of the wallet as given by the customer, else a default value defined by the data holder

The default value defined by the data holder may be null because no such data is stored or contrived on any existing platform. Take for instance email to email payments, the email is the name and participants (like the OP) use this as the reference point. Leaving this up to a data holder will make this field essentially worthless, in fact for recipient use cases it could be much worse (how about "NOT_DEFINED" for every payee listed).

[DougFromPayPal]

I do not agree with the suggestion to change the toUType to a generic 'digital wallet' value. The field is meant to specify the destination of the funds for the payment, hence the original PayPal recommendation of a toUType of digitalWalletPayee. If I have misread/misunderstood the author's intent, please let me know

[nils-work]

Hi @perlboy
The digital wallet name field is intended to contain the display name as the customer may assign and see (or expect to see) in any other channel where a Payee or Payment Schedule is created. If a payee name is not assigned by a customer and other channels simply refer to the wallet identifier, repeating that value from the identifier field would be more appropriate than something unrelated.

Hi @DougFromPayPal
Standards version 1.25.0 has now been published, so you can see this change in context in the BankingScheduledPaymentToV2 schema.
In the hope of providing clarity; digitalWallet is the toUType/field name (a sibling of domestic, international etc.) and BankingDigitalWalletPayee is the schema defining a payee of that type.

As this change has now been published this issue will be closed, but if you have further comments upon review, please consider raising a new issue for consideration in a future iteration.

Thanks