Very Significant. At this point in the ecosystem, it is likely that all ASPSPs have implemented these fields in disparate ways. I strongly recommend OBIE review this topic with all ASPSP stakeholders, and backport the outcome of those discussions to ALL relevant specifications rather than just the most recent one.
TPPs should be advised of expected behaviour going forward such that we can safely parse this information.
Standing Order Frequency Documentation is Incorrect in Multiple Specification Versions
The Standing Order Frequency definition is documented incorrectly in most versions of the Account and Transaction Specification.
The specifications correctly document the following regex:
v1.0
v1.1, v2.0, v3.0, v3.1
(Hereafter I will only refer to versions 1.1+ as v1 is pretty deprecated at this point and not deployed by the CMA9 as far as I know)
As was highlighted in OBSD-5408, TPPs have and continue to experience multiple outsized disruption due to misimplementation of the Frequency field.
We have subsequently discovered that there are multiple documentation issues that might have resulted in this misinterpretation.
v1.1
The Standing Orders - Bulk example in v1.1 contains the following example.
The string
WkinMnthDay(2)
is not conformant with the Frequency Regular Expression.WkInMnthDay:01:01
would be an example of a valid regex.v2.0
As above
v3.0
As above, with the addition of the below issue.
Currently the documentation contains the following table of Frequency Regex examples:
Please note that MANY of these examples are invalid and will not match the documented format. Specifically,
IntrvlMnthDay:1:-1
IntrvlMnthDay:6:15
IntrvlWkDay:1:3
IntrvlWkDay:2:3
WkInMnthDay:2:3
are all invalid. Note generally the lack of leading
0
s for each digit:IntrvlWkDay:1:3
is invalid, whileIntrvlWkDay:01:03
is valid.v3.1
As above
Impact
Very Significant. At this point in the ecosystem, it is likely that all ASPSPs have implemented these fields in disparate ways. I strongly recommend OBIE review this topic with all ASPSP stakeholders, and backport the outcome of those discussions to ALL relevant specifications rather than just the most recent one.
TPPs should be advised of expected behaviour going forward such that we can safely parse this information.
Links:
Standing Order Documentation: