A product can be new to the market, new to the bank or materially changed by a feature, channel, customer group or third party. New-product approval gives leaders a common process for understanding that change before customers and operations carry the consequences.
The process begins with a practical definition of newness
The bank defines which new, modified or expanded products and services enter formal review. Triggers can include a new customer need, delivery channel, geography, pricing structure, technology, data use, vendor, legal relationship or operating process—even when the marketing name stays the same.
An initial screen identifies the accountable business owner, expected customers, proposed use, jurisdictions, systems and material changes from an existing offering. Clear thresholds prevent a significant change from bypassing review while allowing routine maintenance to follow an appropriately simpler path.
The business case includes the customer and operating model
The proposal explains the problem being solved, target customers, product economics, assumptions and measures of success. It maps the full life cycle from marketing and onboarding through servicing, complaints, exceptions, renewal and exit rather than evaluating only the moment of sale.
Leaders ask how customers will understand eligibility, price, key terms, risks and alternatives, and how the bank will serve people when the normal journey fails. Volume and growth forecasts are connected with staffing, funding, capital, liquidity and operational capacity so the plan does not rely on controls that cannot scale.
Cross-functional review turns risks into requirements
Relevant specialists assess credit, compliance, legal, operational, fraud, financial, model, data, technology, cybersecurity, resilience and third-party risk according to the product. The review identifies which existing controls genuinely apply, which must change and which new controls need an owner and testable evidence.
Challenge is most useful before design choices harden. Reviewers document unresolved assumptions, policy exceptions, dependencies and potential customer harm, then specify mitigations, limits, disclosures, monitoring and escalation instead of recording a list of risks with no effect on the launch decision.
Approval sets conditions and requires evidence of readiness
Decision rights match the product's risk and materiality. The approving authority can authorize, reject, return for revision or impose conditions such as a limited customer group, transaction cap, enhanced review, pilot period or completion of specified work before launch.
Readiness evidence can include procedures, contracts, system and control testing, training, customer communications, accounting treatment, reporting, contingency arrangements and ownership of open items. A launch date alone does not override an unmet condition; deviations follow defined escalation and approval rather than informal acceptance.
Post-launch review tests the assumptions against experience
Early monitoring compares actual customers, volume, revenue, complaints, fraud, losses, exceptions, service performance and control results with the approved case. Thresholds identify when the product should be restricted, corrected, escalated or reconsidered before a small mismatch becomes a larger exposure.
A scheduled review confirms whether conditions were closed, controls work at real volume and customer outcomes match the design. Material changes return through governance, while periodic portfolio review and an eventual exit plan keep accountability active after the initial approval meeting.
Read the primary material
Banking Explained prioritizes regulators, official publications and first-party announcements.