Customer is unclear about what they are putting in place when setting up the enduring payment consent. (Medium → Low)

Third Party sends an enduring payment consent resource to the API Provider for authorisation that differs from what was agreed between the Customer and the Third Party. (Low → Very Low)

The Customer feels under pressure to agree the enduring payment consent, but agrees it with the Consent Recipient anyway. (Medium → Very Low)

The Customer is only offered an enduring payment consent as a payment method. (Very Low → Very Low)

The parameters of the enduring payment consent are significantly greater than what is actually needed. (Low → Very Low)

The customer wants to change the account that the consent is loaded against. (Nil risk - is about the design of the standard)

The customer wishes to change the parameters of an established consent but is not able to do so. (Nil risk - scenario not viable)

The API Provider does not permit a given enduring payment consent to be established. (Low → Very Low)

The customer is confused about the role of the Third Party and does not authorise the consent. (Low → Very Low)

Payment initiation outside consent boundaries. (Very Low → Very Low)

Payment processed outside consent boundaries. (Low → Low)

Third Party compromised by a hacker, employee or other and payment(s) initiated via the enduring payment consent. (Low → Low)

A fraudster is able to impersonate a customer who has set up an enduring payment consent using a Third Party app/site and purchases goods or services without the customer being aware. (Low → Low)

The customer’s account that has the enduring payment consent loaded against it is closed. The payment is rejected resulting in a missed payment. (Very Low → Very Low)

Payment processed in accordance with consent and is then disputed. (Low → Very Low)

An enduring payment consent uses the gateway model, where the creditor (Payee) account is not specified in the consent and the Third Party can specify any creditor account for each payment initiated under that consent. The Third Party specifies the incorrect creditor account number and the payment is made into the wrong account number. (Very Low → Very Low)

The customer authorised an enduring payment consent using a steering model (no creditor account specified in the consent). The payment was directed to an account in accordance with the consent but they did not expect it and is disputed. (Very Low → Very Low)

The Customer closes the debtor account that has the consent loaded against it. (Very Low → Very Low)

Customer wants to revoke the consent but is unable to do so. (Nil - not a viable risk scenario)

Customer revoked the consent with the API provider and the Consent Recipient did not know. (Very Low → Very Low)

The Customer revoked the consent with the API provider. A resulting non-payment jeopardises the continued provision of goods and services. (Medium → Low)

The customer revokes the enduring payment consent at the Third Party, but the Third Party does not submit the revocation instruction to the API Provider. This leads to a payment(s) being processed. (Medium → Low)