OCC Bulletin 2016-39, the Comptroller's 2016 standard for compliance risk management in national banks and federal savings associations, expects a risk-based program: an assessment of inherent compliance risk by product, service, and channel; an evaluation of the control environment against that risk; and board-visible governance that keeps both current — and when examiners test whether a bank's program matches its reality, the assessment is the first document they read and the one whose gaps narrate the findings. For banks with fintech partnerships, the document has become the load-bearing artifact of the whole relationship file.
3G Times publishes information, not legal advice. Supervisory expectations differ by agency and charter; this analysis addresses OCC-supervised institutions and their service providers.
What does the bulletin actually require?
The bulletin organizes compliance risk management into pillars. Board and management oversight: the board approves the program, receives meaningful reporting, and holds a named senior officer accountable — the compliance function must be independent enough to escalate. Risk assessment: the bank identifies its compliance risk across consumer, AML, and operational regimes, graded by likelihood and impact, refreshed on a defined cycle and on trigger events — new products, new vendors, new rules. Controls: policies, monitoring, testing, and training sized to the assessed risk, not to habit. Reporting and escalation: issues surface with root causes, owners, and deadlines. The document's philosophy is proportionality — controls scale with risk — which is exactly what makes the assessment the program's keystone: proportionality is measured from it.
How is inherent risk graded honestly?
Inherent risk is exposure before controls, and the honest version resists two temptations. The first is grading to the control ("we monitor this heavily, so it is low risk") — that reversal collapses the methodology, because the residual picture is computed from inherent risk and controls separately. The second is grading to the last exam ("nobody flagged it") — supervisory silence is not evidence of safety. A workable scale runs low-moderate-high on likelihood and impact per obligation area: fair lending by product, UDAAP by channel, BSA/AML by customer segment, privacy by data flow. The fintech-era wrinkles belong in the same grid: a banking-as-a-service program adds bank-developer products to the consumer columns; earned-wage-access and dispute-handling flows add channels; each third-party integration adds a BSA column the bank cannot outsource. The grid's credibility comes from specificity — a file that says "deposit products: low risk" explains nothing, while one that grades overdraft programs by fee mechanics and marketing claims is reading like a program.
What does the control evaluation need to contain?
The control side maps each mitigant to the risk it claims to mitigate, with evidence behind the mapping: the monitoring that samples the actual population, the testing that has happened on a stated cadence, the training tied to role and completion data, the vendor oversight that reviews service-level and complaint data rather than logos on SOC reports. Residual risk falls out of the pairing — what remains after controls — and drives the plan: where residual risk is high, the mitigation plan names owners, resources, and dates that the board's reporting then tracks. The assessment becomes exam-ready when an examiner can walk any line from risk to control to evidence to residual conclusion without a guide.
| Assessment element | Exam-ready property | Common gap |
|---|---|---|
| Risk inventory | Products, services, channels, and regimes enumerated | Partner products missing from the grid |
| Inherent ratings | Rated before controls, with stated criteria | Ratings justified by control strength |
| Control mapping | Each control tied to a specific risk | Generic control lists unlinked to exposures |
| Evidence | Sampling, testing, and training data cited | Assertions without artifacts |
| Residual risk and plan | Conclusions with owners, dates, resources | Conclusions with no follow-through record |
| Governance trail | Board approval, updates on triggers, escalation log | Annual signatures, no change management |
How do fintech partnerships change the exercise?
They multiply the risk surface faster than headcount. A single BaaS program can add several deposit-like products, each with marketing claims the bank did not write, dispute flows the bank must answer for, and data paths crossing vendor boundaries the bank still owns. The assessment handles this the way it handles any complexity: by naming the obligations and grading them where they live — in the partner's product, on the bank's charter. The 2013 interagency third-party guidance and its 2023 successor reinforce the point: the bank's risk assessment must include the risks its service providers introduce, and the partner's own compliance documents feed the bank's control evaluation as evidence, never as substitution. Programs that treat the fintech program as a line item under "vendor risk" consistently under-assess the consumer-protection columns, and examination findings have followed that seam.
What does the exam conversation look like when it works?
The examiner asks for the assessment and receives a document whose date, approvals, and change log match what the bank can show; the risk grid names the fintech program's products in the consumer columns; the control evaluation cites monitoring populations the bank can reproduce. From there the conversation moves to residuals and plans — where the bank argues judgment, not facts. When it fails, the same conversation starts with the examiner reconstructing the bank's risk from findings and complaint data, and the assessment becomes exhibit two.
What does this mean in practice?
- Grade inherent risk blind to controls. Methodology integrity is the document's spine; the reversal error is the most common critique and the cheapest to avoid.
- Refresh on triggers, not just anniversaries. New partner, new product, new rule, enforcement wave in the sector — each is a documented update event.
- Wire the assessment to board reporting. The same residual-risk lines that conclude the assessment should appear, tracked, in what the board sees.
- Bank the evidence as you go. Monitoring samples, test reports, and training completions land in the file the week they happen; reconstructed evidence reads like reconstructed evidence.
The 2016 bulletin has outlived several enforcement cycles because its ask is modest and structural: know your risk, size your controls to it, and show the work. Examinations of that ask are document-driven by design — the assessment that can be walked line by line is the program's best defense.
A closing note on honesty: the assessment is one of the few documents examined both for what it says and for whether the bank believed it. Over-grading risk invites control findings; under-grading invites program findings. The defensible file is the one whose grades the staff can defend line-by-line without the person who wrote them in the room.
Frequently asked questions
How often must the assessment be updated?
The bulletin requires a defined cycle plus risk-based updates; annual is the common floor, with trigger events — new products, partners, or rules — forcing interim updates. The governance trail should show both the calendar and the triggers firing.
Can the assessment be performed by a consultant?
Prepared with, not delegated to. Examiners probe whether the bank's own staff can walk the file and act on it; an assessment no insider understands is a finding wearing a binder.
Does a fintech partner's assessment satisfy the bank's duty?
No. The partner's documents are inputs to the bank's control evaluation; the obligations sit on the charter. Programs that pointed to partner certifications instead of their own grids have been the recurring fact pattern in partnership-related findings.
For more context, read Who the FTC Safeguards Rule Covers, and When Its Incident-Notification Requirement Triggers.
For more context, read ecoa adverse action notices ai.
For more context, read model risk management sr 11-7.