For AISP: OBReadConsent1:

UML diagrams are incorrectly showing the Permissions field as 0..1 in version 3.1.7 and v3.1.8

3. VRP Domestic VRP Response

https://openbankinguk.github.io/read-write-api-site3/v3.1.8/resources-and-data-models/vrp/domestic-vrps.html#obdomesticvrpresponse

1. Fix UML diagram to reflect  Instructed amount field as 1..1 in below objects

   1. OBDomesticVRPInstruction

   2. OBDomesticVRPRequest

   3. OBDomesticVRPResponse

2. Update swagger

Changes removed are struck out and added are in blue

Fix in section to remove 'Revoked' status

https://openbankinguk.github.io/read-write-api-site3/v3.1.8/resources-and-data-models/vrp/domestic-vrp-consents.html#obdomesticvrpconsentresponse

Changes removed are struck out and added are in blue

Fix to section - Consent revocation

https://openbankinguk.github.io/read-write-api-site3/v3.1.9/profiles/vrp-profile.html#consent-revocation

A PSU may revoke consent for initiation of any future payment orders, by revoking the authorisation of VRP Consent, at any point in time.

The PSU may request the TPP to revoke the consent that it has authorised. If consent is revoked with the TPP:

• The TPP must cease to initiate any future payment orders or Funds Confirmations using the VRP Consent.
• The TPP must call the DELETE operation on the VRP Consent resource to indicate to the ASPSP that the PSU has revoked consent.

The PSU may revoke the VRP Consent access via ASPSP's online channel. If the consent access is revoked via ASPSP:

• The ASPSP must immediately update the VRP Consent resource status to Revoked.
• The ASPSP must fail any future payment order request using the ConsentId,  with the Status Revoked.
• The ASPSP must make a Notification Event available for the TPP to poll/deliver Real-Time Event Notification for the event - consent-authorization-revoked.
• The ASPSP must take the necessary action to revoke access e.g. by revoking/expiring the access token provided to the PISP.
• The status of the domestic-vrp-consents must remain unchanged and the PISP must be allowed to request PSU to re-authenticate the same domestic-vrp-consents resource.
• Upon successful re-authentication by PSU, an ASPSP may issue new authorization code and subsequently new access token to the PISP.

• Update UML diagram to make DebtorAccount block option in OBDomesticVRPConsentResponse block.
• Update to swagger.

1. Update OBDomesticVRPInstruction to remove CreditorAgent block and move PostalAddress under OBDomesticVRPInstruction as CreditorPostalAddress
2. Update OBDomesticVRPInitiation to remove CreditorAgent block and move PostalAddress under OBDomesticVRPInitiation as CreditorPostalAddress

• Change to UML
• Change to Data dictionary table
• Change to Swagger

Change 1) Update 

OBVRPFundsConfirmationRequest to make Reference field optional

OBVRPFundsConfirmationResponse to make Reference field optional

• Change to UML

• Change to Data dictionary table

• Change to Swagger

Change 2) Update

OBVRPFundsConfirmationRequest to make Data block mandatory 

OBVRPFundsConfirmationResponse to make Data block mandatory 

• Change to UML

• Change to Swagger

Oct-2021

& 

Nov 2021

For VRPs, the section on Events (https://openbankinguk.github.io/read-write-api-site3/v3.1.8/profiles/vrp-profile.html#event-notifications) states that 

In any such situation where an account linked to avrp-consentcan no longer be used, temporarily or permanently, to make payments, the ASPSP must inform the TPP using events.

The specification should be modified to read:

In any such situation where an account linked to a vrp-consent can no longer be used, temporarily or permanently, to make payments, the ASPSP should inform the TPP using events.

CDRW-3937 - Getting issue details... STATUS

In the Domestic VRPs - v3.1.8 spec data model it says:

Reference (0..1)
RemittanceInformation. Reference
Unique reference, as assigned by the creditor, to unambiguously refer to the payment transaction. The PISP must populate this with the same value as specified in the ControlParameters.Reference field of the consent.

The field does not exist

Spec should be updated to read "The PISP must populate this with the same value as specified in the `Data.Initiation.RemittanceInformation.Reference`"

Change the statement:

A PSU may revoke AISP's access directly with the ASPSP, via the access dashboard. In such a situation:

• The ASPSPs may revoke/expire the access token provided to the AISP.

to read:

...

• The ASPSP must take the necessary action to revoke access e.g. by revoking/expiring the access token provided to the AISP.

Change the Endpoints table Response Object entry  for payment-details

OBDomesticVRPRequestDetailResponse

to read

OBDomesticVRPDetails

VRP

Errata fixes to VRP example 2 and example 3 

https://openbankinguk.github.io/read-write-api-site3/v3.1.8/resources-and-data-models/vrp/domestic-vrp-consents.html#examples-of-periodic-limits

Change Example 3 from

 to

Errata fix to update resources and data models page for VRP - https://openbankinguk.github.io/read-write-api-site3/v3.1.8/resources-and-data-models/vrp/

OBSD-25460 - Getting issue details... STATUS

OBSD-26172 - Getting issue details... STATUS

Errata fix to update enumerations for VRP - https://openbankinguk.github.io/read-write-api-site3/v3.1.8/references/namespaced-enumerations.html

TPP

ASPSP

Aug-2021

Jul-2021

OBSD-25446 - Getting issue details... STATUS

OBSD-25088 - Getting issue details... STATUS

Errata fix to update State model table to remove "Expired" status

https://openbankinguk.github.io/read-write-api-site3/v3.1.8/resources-and-data-models/vrp/domestic-vrp-consents.html#state-model---vrp-consents

Errata fix to update permissions in Transactions API 

https://openbankinguk.github.io/read-write-api-site3/v3.1.8/resources-and-data-models/aisp/Transactions.html#permission-codes

Clarification on 

PeriodType=Fortnight

PeriodAlignment=Calendar

ValidToDateTime

https://openbankinguk.github.io/read-write-api-site3/v3.1.8/resources-and-data-models/vrp/domestic-vrp-consents.html#obdomesticvrpcontrolparameters

PeriodType=Fortnight

PeriodAlignment=Calendar

To refrain from implementing this combination, as the ISO calendar does not support or provide any guidance on when a fortnight should start.

Clarification on time part in the consent -

ValidFromDateTime

ValidToDateTime

The consent period starts and ends at midnight - effectively the time element of the date should be disregarded in computing the date range and pro-rating.

For file payments, the OBWriteFileResponse3/Data/Debtor/Name field only allows a single value. 

Guidance or changes are required for what should be done in situations where the file payments are made from multiple debtor accounts

To be confirmed following completion of FCA consultation on Debtor Name/Account fields

This property is documented to be a class of type ‘OBBranchAndFinancialInstitutionIdentification6’.

This is incorrect and it should be ‘OBCashAccountCreditor3’.

Addressed in v3.17

In the Domestic-Standing-Orders section, the ‘OBDomesticStandingOrder3’ class includes the ‘CreditorAccount’ property.

This property is documented to be a class of type ‘OBBranchAndFinancialInstitutionIdentification6’, although the fields documented beyond that (in CreditorAccount path) are not.

OBSD-16647 - Getting issue details... STATUS

Transaction Identifier. A unique identifier for the transaction. ASPSPs *may *populate this field with the x-fapi-transaction-id of the api operation that lead to the change, or populate it with the same value as jti. 

This should read x-fapi-interaction-id instead of x-fapi-transaction-id

OBSD-16778 - Getting issue details... STATUS

OBSD-15322 - Getting issue details... STATUS

Incorrect multiplicity for OBRisk1/DeliveryAddress/CountrySubDivision

This will be fixed in v3.1.6

Clarify that when an ASPSP receives a request with an incorrectly formatted date, it may respond with a status code of 400 Bad Request and an error code of UK.OBIE.Field.InvalidDate.

The regex pattern for uuidv4 specified for the jti field is incorrect in the specification.

As per the UUID specification (https://tools.ietf.org/html/rfc4122#section-3):

1 The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input.

This has been fixed in the swagger file for v3.2.

The specification will be corrected in the next version.

https://github.com/OpenBankingUK/read-write-api-docs-pub/commit/788eb1f5261177a49e8afaee7f9e52a19c5bda52

Fixed in v3.1.5

Fixed in v3.1.5

Old regex will not accept amounts without a decimal point

Cosmetic changes only.

Fixed in Version 3.1.5

https://github.com/OpenBankingUK/read-write-api-docs-pub/commit/85addb6bd4ef06f78c600a28d4ef2be5c3a5ab1f

These have been fixed in Version 3.1.4

Cosmetic changes only.

These have been fixed in Version 3.1.4

We're having issues with dynamic client registration. The validation for the "iss" field in the OBRegistrationRequest1 object (in DCR v3.1) is as follows:

^[0-9a-zA-Z]{1,18}$

The guidance for this is as follows:

For SSAs issued by the OB Directory, this must be the software_id

But the software_id issued in the OB directory is 22 characters in length so is not valid according to the spec. I've noticed the 3.2 registration spec does allow for this length, but most banks don't support this registration version yet. We can register with banks that don't validate this or banks that implement the 3.2 spec, but by the looks of our registration attempts Nationwide validates the length and doesn't implement the 3.2 spec. I'd imagine there are more banks in a similar position. How do you suggest working around this issue in the mean time?

banks must provide a workaround for. The customer must contact Nationwide directly for support. If he/she is not getting the required support, he/she should raise a new ticket complaining about Nationwide and OBIE Central Testing team will get involved.

This has been fixed in V3.2