OBIE - OBReadAccount2+ Account detail object examples violate swagger specification

[tobypinder]

OBReadAccount2+ Account detail object examples violate swagger specification

The Account resource from version 2 onwards is modelled as OBReadAccount2 in the AIS specifications. These differ from the OBReadAccount1 spec as the OBReadAccount2/Data/Account/Account is marked as 0..n instead of OBReadAccount1/Data/Account/Account's 0..1. This suggests that an account can have multiple Account.Account (account detail) objects attached to it, suggesting that the JSON structure would be an array.

However, all the examples from the Version 2 and Version 3+ specs suggest this is intended to remain a 0..1 association and there does not appear to be a usecase for more than one AccountDetail object being attached to a single account.

V2/V3 Swagger Spec

{
  "Data": {
    "Account": [
      {
        "Account": [
          {
            ...
          }
        ],
      }
    ]
  },
}

Findings

This leads us to the conclusion that either all the examples in the specification are incorrect, or that the Swagger and Documented schema is incorrect across

• AISv2.0
• AISv3.0
• AISv3.1
• AISv3.1.1-RC1 (& prior prereleases)

AISv4.0-draft6 appears to revise this behaviour, and Account.Account objects are rendered as 0..n arrays. This suggests that at some point the intention was to "pluralize" this object, but past experience would indicate that ASPSP implementation teams often build their integrations from the examples and written specification documentation rather than the swagger specification.

Thus it is reasonable to assume given the extensive length of time these specifications have been released in the wild, that there are multiple incompatible implementations of this object.

Conclusion

OBIE must therefore:

1) Correct the AISv2 specification and Swagger files. 2) Correct the AISv3 specification and Swagger files. 3) Correct the AISv3.1 specification and Swagger files. 4) Correct the prerelease AISv3.1.1 and AISv4.0 specification drafts in subsequent releases. 5) Survey each of the CMA9 and non-CMA9 implementing ASPSPs on the specifics of their production platform's interpretation, making the findings available publicly, such as on the ASPSP Documentation space on Confluence 6) Contact TPPs (especially Live-to-market) and ensure that all platform participants are aware of the potential for deviant behaviour across implementations, based on the results of an ASPSP-wide survey performed in [5]. 7) Put steps and procedures in place to ensure that written examples in officially released specification documentation conforms to the published Swagger specification.

References

• OBSD-7257

[andymilligan]

I presumed that the 0..n was to permit multiple ways (schemes) to identify the same account (with the immutable accountId). That doesn't seem unreasonable but it is a presumption and you are right to highlight the inconsistencies.

[tobypinder]

@andymilligan this makes sense, and gels with the fact that it's in the v4 prerelease specs. That said it does seem likely that ASPSPs will implement from the examples, so we'll probably end up having to support both (0..1) and (0..n).