# Domestic VRP consents - v4.0-draft1

• Overview
• Endpoints
  • POST /domestic-vrp-consents
  • GET /domestic-vrp-consents/{ConsentId}
  • DELETE /domestic-vrp-consents/{ConsentId}
  • POST /domestic-vrp-consents/{ConsentId}/funds-confirmation
  • PUT /domestic-vrp-consents/{consentId}
  • PATCH /domestic-vrp-consents/{consentId}
• State Model - VRP consents
• Data Model
• Reused Classes
  • OBProxy1
  • OBPostalAddress6
  • OBRemittanceInformation1
  • OBUltimateCreditor1
  • OBUltimateDebtor1
  • OBRegulatoryReporting1
  • OBCashAccountDebtorWithName
  • OBCashAccountCreditor3
  • OBBranchAndFinancialInstitutionIdentification6
  • OBDomesticVRPInitiation
  • OBDomesticVRPControlParameters
    • Examples of Periodic Limits
      • Example 1
      • Example 2
      • Example 3
      • Example 4
  • OBRisk2
  • OBDomesticVRPConsentRequest
  • OBDomesticVRPConsentResponse
  • OBVRPFundsConfirmationRequest
  • OBVRPFundsConfirmationResponse
• Usage Examples

# Overview

The Domestic VRP Consents resource is used by a TPP to register a consent to initiate one or more of domestic payments within the control parameters agreed with the PSU.

This resource description should be read in conjunction with a compatible Variable Recurring Payments API Profile.

The PISP must call the end-point with the appropriate scope that they have been assigned. The ASPSP may use the scope to limit to functionality to sweeping or non-sweeping usage of the VRP.

# Endpoints

# POST /domestic-vrp-consents

The API endpoint allows the TPP to ask an ASPSP to create a new domestic-vrp-consents resource.

The request payload may contain Debtor Accounts, but the PSU may not have been identified by the ASPSP.

The endpoint allows the TPP to send a copy of the consent (between PSU and TPP) to the ASPSP for the PSU to authorise.

The ASPSP creates the resource and responds with a unique ConsentId to refer to the resource.

The default/initial StatusCode of the resource is set to AWAU.

If the parameters specified by the TPP in this resource are not valid, or fail any rules, the ASPSP must return a 400 Bad Request. In such a situation a resource is not created.

The ASPSP must allow a PSU to have multiple VRP consents for a given account. This could include multiple consents with the same PISP.

The ASPSP must reject a consent request that has Data.ControlParameters.SupplementaryData that it cannot process.

Remittance Information MAY be provided in the Initiation section when a VRP Consent is setup. This means the same Remittance Information MUST be provided by the PISP in the Initiation and Instruction section of each VRP Payment. If each VRP Payment requires dynamic Remittance Information for each VRP Payment then the Remittance Information at the VRP Consent level MUST NOT be captured. The Remittance Information in the Initiation section provided at the VRP Payment level MUST match the Initiation section provided at the VRP Consent level.

Examples:

# GET /domestic-vrp-consents/{ConsentId}

A TPP can retrieve a VRP consent resource that they have created to check its status at any point of time using this API.

# DELETE /domestic-vrp-consents/{ConsentId}

A TPP can delete a VRP consent resource that they have created by calling this API.

# POST /domestic-vrp-consents/{ConsentId}/funds-confirmation

This API endpoint allows the TPP to ask an ASPSP to confirm funds on the DebtorAccount associated with the domestic-vrp-consent.

An ASPSP can only respond to a funds confirmation request if the resource has a StatusCode of AUTH.

If resource has any other Status, the ASPSP must respond with a 400 (Bad Request) and a UK.OB.Resource.InvalidConsentStatus error code.

# PUT /domestic-vrp-consents/{consentId}

This endpoint is only used for migration of consent data across API Standard versions. The ASPSP can choose to implement one or both of the PUT/PATCH endpoints and TPPs should refer to the ASPSP developer portal for information on availability.

This endpoint should not be used to modify content of an existing consent created on the same version. The ASPSP must reject request if a TPP attempts to modify an existing resource which does not require migration to the new format.

The request body should contain the correct schema for the current version of the API specification with any associated enumeration values that have moved to short code format. Values originally supplied in the consent such as account information, control parameters, dates or monetary values must not change and the ASPSP must reject any requests which modify these values.

Successful submission must return the updated consent resource body.

# PATCH /domestic-vrp-consents/{consentId}

This endpoint is only used for migration of consent data across Standard versions. The ASPSP can choose to implement one or both of the PUT/PATCH endpoints and TPPs should refer to the ASPSP developer portal for information on availability.

This endpoint should not be used to modify content of an existing consent created on the same version. The ASPSP must reject request if a TPP attempts to modify an existing resource which does not require migration to the new format.

The request body should contain a partial JSON body containing only the changed schema and any associated enumeration values that have moved to short code format, matching the current API specification. Values originally supplied in the consent such as account information, control parameters, dates or monetary values must not change and the ASPSP must reject any requests which modify these values.

Successful submission must return the full updated consent resource body.

# State Model - VRP consents

The state model for the VRP consents resource follows the generic consent state model. However, it does not use the COND StatusCode.

All domestic-vrp-consents start off with a StatusCode of AWAU

Once the PSU authorises the resource - the StausCode will be set to AUTH.

If the PSU rejects the consent, the StautsCode will be set to RJCT.

The available StatusCodes for the VRP consents resource are:

• AWAU
• RJCT
• AUTH
• CANC
• EXPD

The definitions for the StatusCode:

Changes to the StatusCode, such as being rejected, should be captured in StatusReason, an array of StatusReasonCode, StatusReasonDescription and Path.

# Data Model

The data dictionary section gives the detail on the payload content for the VRP consent API flows.

# Reused Classes

# OBProxy1

The OBProxy1 class is defined in the vrp-profile page.

# OBPostalAddress6

The OBPostalAddress6 class is defined in the vrp-profile page.

# OBRemittanceInformation1

The OBRemittanceInformation1 class is defined in the vrp-profile page.

# OBUltimateCreditor1

The OBUltimateCreditor1 class is defined in the vrp-profile page.

# OBUltimateDebtor1

The OBUltimateDebtor1 class is defined in the vrp-profile page.

# OBRegulatoryReporting1

The OBRegulatoryReporting1 class is defined in the vrp-profile page.

# OBCashAccountDebtorWithName

# OBCashAccountCreditor3

# OBBranchAndFinancialInstitutionIdentification6

# OBDomesticVRPInitiation

# OBDomesticVRPControlParameters

The VRP consent is a common class used in domestic-payment-consents requests and responses

# Examples of Periodic Limits

# Example 1

// created on 06-Jun-2021
{
  "PeriodType": "Month",
  "PeriodAlignment": "Calendar",
  "Amount": "300.00",
  "Currency": "GBP"
}

# Example 2

// created on 05-Jun-2021
{
  "PeriodType": "Month",
  "PeriodAlignment": "Consent",
  "Amount": "500.00",
  "Currency": "GBP"
}

# Example 3

// created on 05-Jun-2021
{
  "PeriodType": "Year",
  "PeriodAlignment": "Calendar",
  "Amount": "500.00",
  "Currency": "GBP"
}

# Example 4

// created on 05-Jun-2021
{
  "PeriodType": "Year",
  "PeriodAlignment": "Consent",
  "Amount": "500.00",
  "Currency": "GBP"
}

# OBRisk2

The Risk block for VRP does not included ExtendedPurpose, used only in International payments, therefore uses OBRisk2.

# Data Dictionary

# OBDomesticVRPConsentRequest

# OBDomesticVRPConsentResponse

# OBVRPFundsConfirmationRequest

The OBVRPFundsConfirmationRequest object must be used to request funds availability for a specific amount in the Debtor Account included in the VRP consents.

# OBVRPFundsConfirmationResponse

The OBVRPFundsConfirmationResponse object will be used for a response to a call to:

• POST /domestic-vrp-consents/{ConsentId}/funds-confirmation

The confirmation of funds response contains the result of a funds availability check.

# Usage Examples

See Usage Examples