The sentence that confuses every fintech founder
A payments company in Toronto gets a term sheet with a security annex from a Schedule I bank, and a line in the covering email saying "we will need to see your alignment with OSFI B-13." The founder reads the guideline, notices it is addressed to federally regulated financial institutions, finds the company is not one, and concludes the requirement is a mistake.
It is not a mistake, and it is not sloppy drafting. Guideline B-13 binds the institution. The institution is accountable to its regulator for technology and cyber risk across everything that supports its operations, and that accountability does not stop at the edge of its own network. When the bank buys your API, your risk becomes part of the risk it has to govern. The obligation stays with the bank. The evidence request lands on you.
That distinction separates the supplier who answers the review in three weeks from the one who spends four months arguing the guideline does not apply. It does not apply to them. It still reaches them.
What Guideline B-13 actually says, and what it does not
Guideline B-13, Technology and Cyber Risk Management, came into effect on 31 July 2022. It applies to federally regulated financial institutions: banks, foreign bank branches, foreign insurance branches, life insurance and fraternal companies, property and casualty companies, and trust and loan companies. Provincially regulated credit unions sit outside it, though many have adopted its structure voluntarily.
The final guideline is built around three domains, each stated as an outcome rather than a control list:
Governance and risk management. Technology and cyber risks are governed through clear accountabilities and structures, with strategies and frameworks that reach senior management and the board. In practice this covers senior management accountability, a technology strategy tied to business objectives, and a risk management framework with a defined risk appetite.
Technology operations and resilience. A technology environment that is stable and resilient, kept current, and supported by sustainable operating and recovery processes. This covers architecture, asset inventory, project governance, secure development, patch and currency management, and disaster recovery with regular testing.
Cyber security. A secure posture that maintains confidentiality, integrity and availability of technology assets, built on identifying threats, defending through layered controls, detecting malicious activity continuously, and responding to incidents with real forensic capability.
What B-13 does not do is prescribe controls at the level a questionnaire does. It states outcomes and leaves the institution to demonstrate how it reaches them, which is why two banks reading the same guideline can send you very different vendor packages.
The domain that moved: B-13's missing fourth section is now B-10
The 2021 draft of B-13 was organized into five domains, one of which was third-party provider technology and cyber risk. Consultation feedback pushed back on having third-party expectations in two places, and OSFI removed that material from the final B-13, stating it would be addressed in the updated Guideline B-10 instead. The final B-13 still mentions third parties in passing: asset management, disaster recovery testing of critical integration points, and cyber response where an incident originates at a provider. But the substantive third-party regime is not in B-13 any more.
So if somebody hands you a mapping document with a fourth B-13 domain on third-party technology risk, they are working from the draft. The material is real, it simply lives somewhere else now, and that somewhere else is the guideline that matters most to you as a supplier.
Guideline B-10 is the one that reaches you
Guideline B-10, Third-Party Risk Management, took effect on 1 May 2024, with foreign bank and foreign insurance company branches given until 31 March 2025. Arrangements predating the effective date were to be reviewed and updated at the earliest opportunity.
B-10 covers governance, management of third-party risk, special arrangements such as standardized contracts, and technology and cyber risk. Its logic is risk-based and proportionate: the institution assesses how critical an arrangement is, then applies controls that match. The pieces that shape what a supplier gets asked for are these.
Criticality assessment. The institution evaluates the severity of loss or harm if the third party fails, and considers substitutability, including how portable the service is and how quickly a transfer could be done. If you sit in a payment path or an underwriting decision, expect to be assessed as critical, and expect everything that follows to be heavier.
Contractual provisions. For critical or high-risk arrangements, B-10's annex material sets out terms the institution is expected to secure: roles and responsibilities, service levels, data security and confidentiality, incident notification, business continuity and disaster recovery obligations, default and termination, and insurance.
Subcontracting. The institution is responsible for identifying, monitoring and managing risk arising from subcontracting. That responsibility converts into a contract clause requiring you to notify on subcontractor change and to extend assurance rights down the chain.
Concentration risk. The institution assesses concentration across dimensions including geography, supplier and subcontractor. You may lose a deal, or be capped in volume, for reasons that have nothing to do with the quality of your controls.
Exit strategy. Documented plans with defined triggers, detailed enough to be executed quickly, covering both planned exit and exit under stress.
Audit and assurance rights. Agreements are expected to give the institution, and OSFI, the ability to evaluate risk management practices and to access audit reports covering the service being performed.
Notice how much of that is contractual and operational rather than technical. That is the part a fintech usually underestimates.
Mapping B-13's domains onto the Trust Services Criteria
SOC 2 is built on the Trust Services Criteria: the Security category, which is always in scope and is expressed as the common criteria CC1 through CC9, plus the optional categories of Availability, Processing Integrity, Confidentiality and Privacy. The mapping to B-13 is better than sceptics expect, in three places.
Governance and risk management lines up with CC1 on control environment and organizational structure, CC2 on communication and information, CC3 on risk assessment and objective setting, CC4 on monitoring activities, and CC5 on control activities. A well-run SOC 2 already produces the board reporting cadence, the risk register, the defined roles, and the policy set that this domain expects. The vocabulary differs. The artifacts are largely the same artifacts.
Technology operations and resilience maps to CC7 on system operations, CC8 on change management, and to the Availability category if you have elected it. Asset inventory, change control, incident management, monitoring and backup all sit here. If you scoped Security only and skipped Availability, this is where the gap starts to show, because B-13's resilience expectations are not optional the way the Availability category is.
Cyber security maps to CC6 on logical and physical access, CC7 on detection and incident response, and CC9 on risk mitigation. Access control, encryption, vulnerability management, logging, and incident response are all common ground.
For a first-pass review, a clean Type II over a sensible scope moves a real portion of the questionnaire from "unanswered" to "evidenced by an independent report."
Where the mapping fails completely
Four areas do not map at all, and these are where fintech onboarding stalls.
Resilience testing with a named recovery objective. SOC 2 will confirm you have a business continuity and disaster recovery process and that you tested it. B-13 pushes toward recovery objectives set against the criticality of the service, and toward testing that includes critical third-party integration points. An institution treating you as critical will ask what your recovery time and recovery point objectives are, whether you have proven them, and whether the test involved your own upstream providers. A Type II opinion does not carry those numbers.
Incident notification timelines. An FRFI has to report a reportable technology or cyber security incident to OSFI within 24 hours, or sooner if possible, under OSFI's incident reporting advisory. The institution cannot meet that clock if it learns about your incident in four days. So the clock gets pushed into your contract, usually as a notification window measured in hours. SOC 2 tests that you have an incident response process. It says nothing about how fast you tell a specific customer, because that is a contractual term, not a control objective.
Concentration and substitutability. No Trust Services criterion addresses whether the institution could replace you, how long that would take, or whether too much of its book depends on one supplier. This is assessed about you, not by you, and no report answers it.
Subcontractor transparency. SOC 2 handles subservice organizations through the carve-out or inclusive method, and a carve-out report deliberately excludes the subservice organization's controls, listing instead the complementary controls you assume it performs. B-10 expects the institution to understand and monitor your subcontracting chain. A carve-out report is, from the institution's point of view, a documented hole. That does not make it wrong. It makes it something you have to fill in separately.
What an FRFI vendor security review actually asks for
The package varies, but the shape is consistent once an arrangement is treated as critical:
- The full SOC 2 Type II report, not the certificate image, not the summary, with the observation period and every exception and management response
- A completed security questionnaire, frequently several hundred items, often the institution's own format rather than a standard one
- Evidence of penetration testing by an independent party, with scope, methodology, findings and remediation status, usually within the last twelve months
- Architecture and data flow documentation showing where institution data lives, transits and is backed up, with hosting regions named
- Your subcontractor and subprocessor list, with what each one touches
- Business continuity and disaster recovery plans, the last test report, and stated recovery objectives
- Your incident response plan and your customer notification commitments in hours
- Insurance certificates, commonly cyber liability and errors and omissions at specified limits
- Financial statements or another viability signal, since financial failure is an operational risk
- Named exit and transition provisions: data return format, deletion certification, transition assistance period
- Right to audit language, and agreement that the right extends to the regulator
Some of that is security. A lot of it is corporate. The reviewer is not only assessing whether you are secure, but whether the institution could survive your failure.
How a SOC 2 Type II report answers part of it
A Type II report over a twelve month observation period, scoped to the systems the institution will actually use, with Availability and Confidentiality elected alongside Security, and with no exceptions, will typically retire the access control, change management, monitoring, logging and personnel sections of the questionnaire outright. That can take weeks out of the review.
What it will not do is answer the resilience numbers, the notification clock, the subcontractor chain, the exit plan, or the concentration question. Those come from you, in writing, in the contract and in the supporting documents.
Three practical points. Scope has to cover the production environment the institution will touch, not a subset that was convenient at audit time. Bridge letters matter, because if your period ended eight months ago the reviewer will ask what has happened since. And exceptions are survivable when the management response is specific and dated, damaging when it is generic.
The four things to build beyond SOC 2
Exit and transition, written down. A short document covering data export format and timeline, deletion and certification, transition assistance duration and rate, and what happens on your insolvency. Write it before you are asked.
Subcontractor transparency as a maintained register. Every fourth party that touches institution data: name, function, data category, hosting region, assurance you hold over them, and your notice commitment for changes. Put change notice in the contract, with a period long enough for the institution to object.
Incident notification in the contract, with a clock you can meet. Decide what detection to notification looks like on a bad day, then commit to something you can hold under pressure. Define what triggers notification, who receives it, through what channel, and the follow-up cadence. Align it with your breach obligations under PIPEDA, and under Quebec Law 25 if you handle Quebec personal information, so you are not running two incompatible clocks.
Resilience evidence with numbers. Stated recovery time and recovery point objectives per service, a test performed at least annually, a written result including what failed, and an understanding of your own critical upstream dependencies. This is the most common gap we see in fintech suppliers who already hold a clean SOC 2.
Sequencing this without stalling the deal
Start from the institution's package rather than from a framework. Get the questionnaire and the draft schedule early, before the security review formally opens, and run a gap assessment against that actual document. It will tell you which items your existing report answers, which need evidence you have but have not assembled, and which need something built. The output is a findings register, and the register is what makes remediation scope and price honest, because nobody can price remediation credibly before the gaps are known.
Two phases, in that order, is how we run this: a gap assessment that sets scope and produces the findings register, then remediation scoped and priced from those findings. Anyone quoting remediation before the assessment is quoting a guess.
If your SOC 2 does not exist yet, the question is whether to pursue Type I first for the near-term deal and build toward Type II, or go straight to Type II and accept the observation period. That depends on the institution's tolerance and your contract timeline, and it is worth deciding deliberately rather than by default.
Questions to ask whoever helps you prepare
- Have they taken a Canadian company through an FRFI onboarding review that they can describe, and can that work be referenced?
- Is remediation priced before or after the gap assessment?
- Who signs the audit opinion, and is that a licensed CPA firm independent of the readiness work?
- What are the practitioner's credentials beyond a baseline certification?
- Which entity signs the contract, and under which province's law?
- Where does your engagement data live while the work is running?
Those are as fair to ask of an advisor as the institution's questions are to ask of you.
Next step
If a bank or insurer has sent you a security schedule and you are working out what your current position actually answers, the starting point is a gap assessment against that specific package, not against a generic framework. TrazTech runs SOC 2 and ISO 27001 readiness, penetration testing, security questionnaire completion and fractional CISO work for Canadian startups and SMEs, and the Principal, Jacob Masse, is a published security researcher with five CVEs on the record.
Send the schedule and the questionnaire. We will tell you which parts your existing evidence already covers and which need work, before anyone talks about scope or price.