Approval records and operating controls for new products and material changes
Consider a product that receives a favorable legal memo and still produces a loss. The bank approved the activity before anyone established who owed money to whom, who held customer funds, who could reverse a transaction, or how the bank would operate if the vendor failed. A sound approval process resolves those questions before launch and preserves evidence that the answers match the product customers actually receive.
Why product governance matters
A familiar product can require a new approval when its delivery changes. A deposit account offered through a fintech partner may introduce a separate customer ledger, outsourced support, concentrated funding, and a new route for customer complaints. A payment service moved from batch processing to immediate settlement may require different limits and staffing. The commercial label may remain unchanged even though the bank is accepting materially different risk.
Require the business line to submit a one-page activity definition before preparing the full approval package. It should answer six questions: Who owes money to whom? Who holds customer funds? What ledger records the obligation? When does settlement become final? Which entity communicates with the customer? Which entity can reverse a transaction, and under what conditions? Identify each legal entity by name. If an answer is unknown, return the proposal for clarification before committee approval.
Decide which approval process applies
Screen both new offerings and material changes to existing offerings. A change in customer type, geographic reach, vendor, funding source, transaction speed, or payment capability should be routed to Risk and Compliance before implementation. The screening record should state either why the existing approval still covers the activity or which additional review is required. A technology release is not exempt merely because no new product name appears on the website. The OCC’s new activity principles provide a useful starting point for OCC-supervised banks. [1]
Next, identify the provider of record and the affected balance sheet. Determine whether the customer holds a deposit, an interest in custodial assets, a prepaid balance, or another claim. Finance and Legal should use the same funds flow to assess accounting, liquidity, capital, insurance, and permissible activity questions. Record any required regulatory filing, approval, or consultation and make its completion an express launch condition.
Map the customer journey from marketing through termination. Inaccurate marketing, weak enrollment evidence, unauthorized administrators, poor exception handling, or unclear termination procedures can undermine an otherwise permissible product. Compare the actual journey with the legal analysis before launch.
Test a fraudulent payment, a disputed administrator change, a vendor outage, and a failed reconciliation. Include the failure most likely to threaten this particular product, such as a reserve depositor withdrawing its entire balance or a processor becoming unable to deliver customer records. For each scenario, identify who can stop transactions, how balances will be established, and what the customer will be told.
Assemble an approval package that can be implemented
The package should connect the business case to the proposed controls. Include target customers, projected volume and exposure, funds and data flows, legal analysis, financial assumptions, BSA and sanctions review, information security, privacy, and third-party diligence. Attach the actual customer documents, marketing claims, implementation requirements, complaint process, and launch plan. A committee cannot meaningfully approve a customer promise it has never seen.
Assign each material risk an accountable owner, a control, and a record showing that the control operates. For example, an approval might require Operations to reconcile the partner ledger to the bank ledger each business day, escalate unresolved differences above a stated amount, and suspend new transactions if a break remains unresolved beyond the approved period. Management should choose those amounts and periods for the product rather than leaving them for the implementation team to infer.
Approve the limits and conditions of a pilot
A pilot limits exposure but does not suspend applicable law or contractual duties. Specify the customers, accounts, transaction limits, duration, and permitted functionality. If a proposed pilot depends on an exception, identify the exception, its owner, its expiration, and the control that addresses the resulting risk.
Do not allow an open implementation item to become an informal condition of approval. Classify it as either a condition that must be completed before the first customer is activated or a permitted post-launch item with an owner and deadline. Before expansion, require a written comparison of pilot results against the approved criteria, including fraud, complaints, outages, and reconciliation exceptions.
Review product performance after launch
Set review dates when the product is approved. A bank might review initial operations after 30 days and financial and risk performance after 90 days, with a longer review for products whose behavior takes more time to emerge. Those intervals are management choices, not universal regulatory deadlines. The review should compare actual behavior with the assumptions on which approval depended.
The product owner should maintain a conditions register showing each approval condition, the supporting evidence, completion date, and approving function. Vendor reports should be tested against the bank’s own records when possible. For material outsourced functions, the bank also needs access to records and an executable transition plan if the vendor relationship ends. [2]
Report exceptions that change the approved risk
Board reporting should concentrate on material exposure and variance. Show actual versus approved balances and volumes, fraud and operational losses, unresolved breaks, complaints, outages, policy exceptions, and partner concentrations. Explain what management did when a trigger was breached. A report that merely lists growing revenue and customer counts does not show whether the product remains within the approved risk appetite.
Set escalation and suspension triggers before revenue creates pressure to continue. If a critical reconciliation cannot be completed, a required control fails, or a concentration exceeds its approved limit, the record should identify who decides whether to restrict or stop activity. The committee should also state when a change requires reapproval. Authentication controls should follow the risks of the access and transaction capabilities being offered. [3]
The management deliverable
- Adopt the one-page activity definition and require the six answers before committee review.
- Maintain a launch record that identifies required approvals, outstanding conditions, exposure limits, and evidence that controls were tested.
- Assign a product owner with authority to escalate breaches and require a recorded decision before expansion or material change.
Sources and application
[1] OCC Bulletin 2017-43. New, Modified, or Expanded Bank Products and Services: Risk Management Principles, October 20, 2017. Applies to OCC supervised institutions.
[2] Interagency third-party guidance. Interagency Guidance on Third-Party Relationships: Risk Management, June 2023; Federal Reserve SR 23-4. Risk management guidance, not a new regulatory requirement.
[3] FFIEC authentication guidance. Authentication and Access to Financial Institution Services and Systems, August 2021. Risk-based guidance covering customers, staff, third parties, and system access.
Reviewed through October 24, 2026. General information; apply governing law and institution-specific facts. Recommended controls and examples are not universal legal requirements.