Decision Proposal 51 - Scheduled Payments

JamesMBligh commented 5 years ago

This issue relates to the end points and payloads for Scheduled Payments. Scheduled Payments are the payments that the customer has registered with a bank to occur on a regular basis.

The decision proposal is attached below. Feedback will close on the 22nd May. Decision Proposal 051 - Scheduled Payments.pdf

JamesMBligh commented 5 years ago

The proposal has now been published

assem-ali commented 5 years ago

Hi James, For scheduled payments setup using a joint account as the source, are you expecting the schedules setup by both parties to be returned irrespective of the authorised user, or only the schedules setup by the authorised user?

In our digital channel, only the schedules setup by the logged in user are presented.

JamesMBligh commented 5 years ago

Hi @assem-ali, as far as I am aware there is nothing in the rules or legislation to clarify this so I would be leaning on the previous decisions that have been made around principles and non-functional requirements to resolve this.

As a result, I would suggest that you should align with your existing digital channel experience as this is what the customer would be expecting. This is also supported by the underlying principle of CDR being able sharing the data owned by a customer and, in the experience created by your channels, the schedules created by another customer would appear to be owned by that other customer.

Does that make sense as a position?

assem-ali commented 5 years ago

Hi @assem-ali, as far as I am aware there is nothing in the rules or legislation to clarify this so I would be leaning on the previous decisions that have been made around principles and non-functional requirements to resolve this.

As a result, I would suggest that you should align with your existing digital channel experience as this is what the customer would be expecting. This is also supported by the underlying principle of CDR being able sharing the data owned by a customer and, in the experience created by your channels, the schedules created by another customer would appear to be owned by that other customer.

Does that make sense as a position?

Thanks James, will take the channel parity as the principle here as you indicated.

anzbankau commented 5 years ago

Hi James,

A few comments on the scheduled payments endpoint:

The scheduled payments APIs are currently based on the account resource (i.e. GET /banking/accounts/payments/scheduled), however we model these as a resource of the customer more broadly as it is not fundamentally part of the account. We would recommend that a similar approach to the Payees end point is taken and that the resource is moved directly under banking, i.e. GET /banking/payments/scheduled this will simplify data recipient calls and data holders implementation.
For certain types of scheduled payments, it may be that neither the next amount nor next date will be known at the time of the enquiry – e.g. for automatic credit card payments the payment date (and possibly amount) will be based upon the statement, which may not have been issued. These fields should be optional (or conditional until the payment date and amount is known).
Similarly, for such payment types the interval is not one that can be accurately represented as an interval - should an approximate interval be used (e.g. monthly), or should the API allow some way of specifying that the interval is "complex" and not purely interval based.
In ANZ we have the option to “skip” the next instance of a recurring payment. Currently we cannot see a way to accurately represent this in the current API's ("status" is close, but neither "ACTIVE" nor "INACTIVE" are totally accurate). Can we get a change to represent this feature.
The “finalPaymentDate” is documented as the date of the last payment. ANZ allows users to specify an end date, but that may not be the date of a payment (e.g. I schedule a recurring monthly payment starting on the 1st Jan, and set the end date to be the 15th April – but the final payment date in that case would be 1st April, not the 15th. This can be calculated with some complexity based on calendars and it also “loses” information given by the customer. It would be best if this scenario can be catered for in the API.
"lastWeekDay" component doesn't match with the specified recurrenceUType options - we believe it should be "lastDayOfInterval".
"onceOff.paymentDate" appears to be redundant with "nextPaymentDate".

commbankoss commented 5 years ago

Commonwealth Bank supports the decision proposal with a minor adjustment to accountID definition. It is unclear what account ID (from and to) will be used. Our recommendation would be that the ID does not contain any sensitive consumer information such as account number or BSB, the identifier should be compliant with the ID permanence rules. We oppose any on sharing of information about another consumer without their explicit consent. We support that the decision proposal for schedule payments is independent of the Payee endpoint.

As the proposal stands the response will change dependant on the scope. The data recipent and holder will need to monitor the scope for any changes. For transfers between accounts the consumer owns the destination account and it can vary between accountID or domestic formats weather the destination account is included within the current scope. For accounts the customer doesn’t own the domestic format may include the PayeeID or not depending if it within the consumers scope. Commonwealth Bank is concerned that we are introducing data leakage.

NationalAustraliaBank commented 5 years ago

NAB has the following feedback on this decision proposal for Scheduled Payments end points.

Sensitive information

We would like to draw attention to our previous feedback related to the proposed sharing of sensitive payment related information, captured in https://github.com/ConsumerDataStandardsAustralia/standards/issues/32#issuecomment-434957636 and https://github.com/ConsumerDataStandardsAustralia/standards/issues/39#issuecomment-441159032. Our previous feedback is also relevant to this decision proposal.

One-to-many payment instructions

NAB customers are able to schedule payments under a single payment instruction which comprises of multiple funds transfers from one customer's account to a set of other accounts. Whilst this kind of instruction can be partially represented in the proposed API, there is no provision in the proposal that would allow Data Recipients to identify the set of payments that belong under a common payment instruction. We would like to see this supported within the response or as a separate payment details endpoint.

Additional payment types

Continuing on the theme within the feedback from @anzbankau https://github.com/ConsumerDataStandardsAustralia/standards/issues/51#issuecomment-494196242 regarding variable / unknown payment data, there are other payment types like automatic saving plans (see direct debit authorisations below) and customer configurable sweep in / out transfers that are both date based or event based. To support these payment types there would be both new fields and objects required as well as changes to currently mandatory fields.

Direct debit authorisations

Scheduled payments under a direct debit authorisation (different to decision https://github.com/ConsumerDataStandardsAustralia/standards/issues/57 for direct debit deductions), where the customer has received third party authority to debit funds from a third party account and credited into their own account, is not catered for within the decision proposal. Using a negative AmountString for these payments to reverse the from (source) and to (destination) objects is potentially confusing. Also, should there be a constraint or new data type for the amount field being a positive amount?

Non-consumer complex payment types

Noting that it is not scoped in the draft rules, this decision proposal does not cater for complex payment types that would be seen outside the consumer banking domain, for example, complex payments within corporate and institutional banking. Should this come into scope, we expect that this be catered for in later versions of the standards.

JamesMBligh commented 5 years ago

Thanks for the feedback. This is all very useful and will be reviewed and incorporated. I'll be closing down feedback on this thread. Any additional feedback or points of clarification can be posted on the current open thread for feedback (#67)

JamesMBligh commented 5 years ago

Please find attached the final decision covering this issue Decision 051 - Scheduled Payments.pdf

ConsumerDataStandardsAustralia / standards