Happy 1033 Final Rule Day!
The final consultation is over and the 1033 rule has been published – the rule itself is a pretty straight forward, coming in at just 38 pages, but the consulting report with the addendums from the draft rules published this time last year runs to nearly 600!
Interestingly, not a huge amount has changed from the draft rules – there is a degree of clarification and tightening up of rules, some good, some I disagree with. Generally it is positive but there’s a lot to digest.
There’s a lot of interesting information in the feedback too that is worth reviewing, including our paper on the challenge of keeping specifications, APIs and documentation up to date. The report and rule both cover this topic in quite some detail too.
High Level Thoughts From An Obsessive API Performance/Conformance Mind
- This is a data right for consumers – and it’s long overdue.
- Strong NO to screen scraping (despite a lot of push back from some in the industry).
- There is a solid performance metric set: availability of 99.5%, excluding downtime.
- Providers will need to track uptime and also scheduled vs. unplanned downtime – this is not a trivial task.
- The latency requirement was removed – this is a good and bad thing in my mind.
- The draft rules called for a 3500ms response time. This is far too slow, so it’s good to see that was removed.
- The final rule calls for “commercially reasonable” response times as defined by Black’s Law for the term. It will be interesting to see how this is litigated.
- Metrics must be made public by the end of the month following
- This is extremely generous (in my mind) and clearly several other responders to the draft pushed back.
- A developer interface must be provided and reasonable efforts to maintain it and keep it up to date must be made.
- In this section, APIContext gets name checked, and as we point out, that might not be entirely straightforward, but it is essential.
- There will be Standards Setting Bodies defined – obviously we assume that one will be FDX but the rule leaves that door open.
- The timeline has been pushed back – the first cohort do not have to be compliant until April 1, 2026 now – 18 months from now.
- The rule does open the door on additional compliance risks around products for Reg E (bank accounts) and Reg Z (Credit Cards & Loans), specifically around data provisions. This aligns with what we have been seeing in the UK, Australia, Mexico and other countries.
Other thoughts – what isn’t defined…
I would have preferred a stronger statement on a Standards Setting Body. Don Cardinal and the team at FDX have done good work there and I am not convinced by the current, in my opinion, vague language on the standard itself.
There is a LOT of comment on security and statements on the approach but nothing specific on how that should be achieved. That is left as open to be determined by the approved Standards Setting Body. I think this does represent a missed opportunity.
Smaller institutions are at a disadvantage with implementing some of this technologically. There isn’t a lot that can be done about that – we see the same in the UK but where the US is different is that there are a LOT of them who did push back that this will cost them a lot. I am not entirely convinced that it will be a lot, and I think the costs of inaction will be higher.
My Key Points (and we do have a product for you for this)
- Start planning now on how to measure and report that 99.5% number
- Make sure your developer interface and API interface don’t drift too far
- Have a strategy for tracking performance against availability in meaningful ways you can defend as commercially reasonable
- Put in place a system to check compliance in a testable way
I’m going to be talking about this at Money20/20 next week, feel free to reach out on LinkedIn or email for a meeting.