Most payment companies treated Canada's Retail Payment Activities Act as a legal project. They hired counsel, filled in the registration, filed it with the Bank of Canada, and moved on. Then the confirmation arrived and a quieter realization followed: the filing was the cheapest part. Everything the filing promised now has to exist, run, and produce evidence, every single day.
I have been through licensing and registration work across Lithuania, Cyprus, Malta, the UK and Canada, and the pattern is always the same. The legal phase ends. The operational phase never does. RPAA is a clean example of this, because the Act is not really asking whether you have documents. It is asking whether your company behaves in a certain way, continuously, and can prove it.
What the Bank of Canada actually supervises
Read the RPAA obligations as an operator, not a lawyer, and they sort into three ongoing workloads.
First, the operational risk and incident response framework. The Act requires every registered PSP to establish, implement and maintain a framework covering risks to its retail payment activities: system failures, cyber incidents, third party outages, fraud. The key words are implement and maintain. A framework that lives in a PDF and was last touched at registration is, functionally, a violation waiting for its first incident.
Second, safeguarding of end-user funds. If you hold end-user funds, they must be held in trust or insured, segregated from your own money, and you need a ledger that can show, at any moment, that the safeguarded amount covers what you owe users. This is not a quarterly exercise. Funds move daily, so the proof has to move daily.
Third, reporting. An annual report to the Bank of Canada, notification of significant changes before you make them, and incident reports when something material breaks. Incident reporting is the one that hurts, because it arrives exactly when your team has no spare capacity: something is on fire, and now you also owe the regulator a structured account of it.
Where PSPs actually fail
Not at registration. The Bank of Canada published its registration outcomes, and the companies that were refused mostly failed on paperwork basics. The failures that matter come later and look like this:
The risk framework was written by an external consultant and nobody inside the company owns it. Twelve months later, the org chart has changed, two vendors have been swapped, and the framework describes a company that no longer exists.
Safeguarding reconciliation is a spreadsheet that one person updates when they have time. On most days the number is right. On the day it matters, during an incident or an audit, nobody can prove what the position was three Tuesdays ago.
Incidents get fixed but not documented. Engineers restore the service in four hours, everyone moves on, and there is no record that meets the reporting standard. The operational event was handled. The compliance event was not.
None of these are legal failures. They are all operational failures, and they are all failures of routine: things that had to happen every day and quietly stopped happening.
The daily machine, and what can run itself
Here is the honest breakdown of the recurring RPAA workload, and what we have found can be automated safely. The distinction that matters: automate the evidence and the routine, keep humans on the judgment.
Safeguarding reconciliation is the clearest win. Pulling balances from your safeguarding account, comparing them against the user liability ledger, flagging any shortfall, and writing a timestamped evidence record: this is deterministic work. An automated agent can run it every morning, file the proof, and escalate only when the numbers disagree. A human reviewing an exception beats a human doing arithmetic.
Framework maintenance can be semi-automated. An agent can watch the inputs that make frameworks go stale: vendor list changes, new system deployments, org changes, and flag the sections of the risk framework that reference them. The rewrite still needs a human, but the detection of drift does not. Most companies fail here not because updating is hard, but because nobody notices updating is due.
Incident documentation is the best use of AI drafting I know in this space. The facts of an incident already exist in your monitoring tools, tickets and chat logs. An agent can assemble the timeline, draft the structured incident record in the shape the regulator expects, and hand it to a human for review while the incident is still fresh. What used to be a dreaded afterthought becomes a review task.
Annual reporting becomes assembly rather than archaeology. If the daily evidence exists, the annual report is a compilation job. If it does not, the annual report is a reconstruction job, and reconstructions are where inconsistencies get created.
What should not be automated: the risk judgments themselves, the decision of whether an incident is material enough to report, and anything where the regulator expects accountable human reasoning. Automation that quietly makes those calls is not efficiency, it is a finding waiting to be written.
The uncomfortable question
If the Bank of Canada asked you tomorrow to show your safeguarding position for a random day last month, with evidence, how long would it take your team to produce it? If the answer is measured in days, the gap is not legal. Your lawyers did their job. The gap is operational, and it compounds quietly until the day it is tested.
This is the work Novafin does: we build and automate the operational layer behind registrations like RPAA, so the evidence produces itself and your team handles exceptions instead of routines. If you want a structured view of where your own gaps are, that is exactly what our diagnostic is for.