The Missing Layer in Banking

Every Revenue Decision a Bank makes is a margin decision. The price on a renewal. The waiver granted to keep a relationship. The competitive offer launched when a rival moves on rate.

Banks have spent years modernizing the systems that carry these decisions out. The decisions themselves still depend on the spreadsheets a Relationship Manager keeps, the time they have to prepare, and the knowledge in their heads.

The reason is structural. The systems a Bank already owns were built to process transactions, not to make Revenue Decisions. The Commercial Logic that should drive those decisions, the products, the pricing, the programs, was placed wherever it would fit. It lives inside the Core, across channel systems, and on spreadsheets on individual desks. No layer was ever made responsible for the Revenue Decision itself.

Every Bank has a System of Record. Until now, few have had a System for Revenue Decisions. That is the gap, and it is where a Bank’s real revenue lives.

Enterprise Profit Maximization, the engine at the center of ArcOne BankOS, exists to close it. It is not another pricing application. It is the Revenue Operating Layer where a Bank defines how it prices, executes those decisions against any Core, and governs every one of them.

The Product Catalog, Pricing, Relationship Programs, Rewards, Waivers, Fee Strategy, Intelligence, and Governance are not separate capabilities. They are one platform, seen from different angles, and it is where a Bank runs its Revenue Business, across retail and commercial banking.

Figure 1.  Banks systematized transaction processing decades ago. EPM gives the Revenue Decision the same discipline.

Figure 2.  Revenue Decisions get a dedicated operating layer, above the Core that records the transactions beneath.

Banking Depth

The platform rests on depth a Revenue Manager will recognize. EPM calculates earnings credit with reserve requirements, investable balances, interest, and offsets for deposit accounts and relationships of accounts. It produces the analysis statement the Treasury Client expects.

It runs multi-tier pricing, models a prospect or renewal with a full pro-forma before anyone commits, and carries a relationship from the price, rate, or fee that is set to the statement the Client receives. This is not a billing tool adapted for banking. It understands an ECR plan, a relationship hierarchy, and a fee schedule the way a Banker does, and that depth is what lets it carry the rest.

Where the Bank Competes

A Core knows account types. It knows an account is a checking account, a savings account, or a commercial deposit. EPM knows how the Bank competes.

Its Product Catalog holds the pricing strategies, bundles, promotional offers, benefits, eligibility rules, tiers, exceptions, and commercial product variants. This is where a Product Manager decides what the Bank sells, to whom, on what terms, and at what price.

The Catalog is not a list of products. It is where the Bank’s effective-dated commercial strategy is expressed and changed. When that strategy lives in one place rather than scattered across the Core, the channel systems, and spreadsheets, the Bank can see what it is offering and adjust it deliberately.

Figure 3.  The Core defines what a Bank sells. EPM defines how the Bank competes.

Moving Commercial Logic Out of the Core

Because that logic lives in the Execution Layer rather than the Core, a change no longer has to wait on the Core. In most Banks a new product variant or a pricing change waits on a Core release and a testing cycle that can run a quarter or more.

EPM moves the work to the teams who own it. They configure a new offer or reprice a tier in days and take it to market without a Core change. It runs on whatever Core the Bank already has, mainframe or modern, reading the book of business and understanding it as banking from the day it connects, with no translation project and no rip and replace.

Over time the pattern compounds, and it does not replace the Core. It modernizes it. As more of the Products, Pricing, Rates, Relationship Programs, Rewards, Tiers, and Fee Strategies move into EPM, the Core becomes smaller and returns to the work it was built for, the Ledger, posting, settlement, and transaction processing.

The commercial capability above it becomes richer, innovation moves faster because a change no longer waits on a Core release, and risk falls because the deposit Ledger is touched less often. This is the Core Modernization path at the center of the BankOS story, and a Bank can travel it without replacing the system it depends on.

Figure 4.  Commercial innovation moves into EPM while the Core focuses on secure transaction processing.

One Revenue View Across the Bank

Revenue Decisions are only as good as the information behind them. EPM brings together products, Customer relationships, pricing, transactions, balances, and operational events into a single operational model for revenue. Whether the data originates from multiple Core Banking platforms, Treasury systems, digital channels, or Customer applications, EPM operates on one consistent view of the business. The Banker works from one picture of the Customer, not multiple disconnected systems.

Working the Portfolio

EPM does not wait to be asked. It watches the Bank’s portfolio and brings what matters forward. A relationship priced below where comparable accounts sit. A renewal at risk. A Client showing early signs of churn. Revenue leaking through waivers, tiered pricing, and exceptions that have drifted past approved terms. A policy exception that needs review. A competitor’s move on rate.

Each is surfaced with the rationale and the margin impact attached. The Banker spends less time assembling the picture and more time deciding on it, and the issues that once came to light only at renewal, or in hindsight, now appear while there is still time to act.

AI Reasons, EPM Executes

Intelligence runs throughout the Revenue Operating Layer. The AI monitors, predicts, recommends, explains, and simulates. But a recommendation is not a revenue outcome.

A model can propose a repricing or flag a leaking waiver; the Bank earns nothing until that proposal is applied to its pricing, its statements, and its Ledger. EPM operationalizes the recommendation. It applies the decision the same way every time, only after the approval the Bank requires, and against the Bank’s own configured pricing and policies rather than a model’s estimate.

This is the distinction that matters in banking. A recommendation informs a decision; the platform audits the decision and carries it out. Deterministic Execution, governed, approved, and repeatable, is what a Bank can trust with its pricing, and it is what separates a system a Bank runs on from a tool that only advises.

Figure 5.  AI proposes the move; EPM executes it under the Bank’s approval — the boundary that makes AI safe to trust with pricing.

One Version of the Truth

Every decision the platform executes carries its explanation with it. When a Customer questions a charge, the Officer has the answer in seconds, in plain language. The fee was not charged because the balance stayed above the qualifying threshold through the measurement period, with a grace period if it falls within.

When a Pricing Committee changes a price or a rate for a segment, the change triggers the required Customer notices and flows through to statements and disclosures, with no separate project. When an Examiner asks what a Customer was quoted, and why, on a date two years earlier, the Bank reconstructs it exactly, because the reason was effective-dated and recorded with the price or rate when it was set.

The Customer, the Relationship Manager, the Pricing Committee, the Internal Auditor, and the Regulator all receive the same answer, because the reason lives with the decision. Nothing changes until a person approves it. The Bank keeps one version of the truth.

The Next Decade in Banking

Banks have spent decades optimizing how they process transactions. They are fast, accurate, and reliable at moving money and keeping the Ledger. The next decade is about a different problem, how a Bank makes its Revenue Decisions, and whether it can make them well, consistently, and at speed.

Seen end to end, the picture is simple. Catalog, Pricing, Relationship Programs, Rewards, Fee Strategy, Intelligence, and Governance are not separate capabilities a Bank stitches together. They are expressions of one operating model, and EPM is where that model runs.

Define, Price, Recommend, Approve, Execute, Audit, and Optimize are not a set of features. They are one continuous cycle, run in one place.

Figure 6.  Revenue is not a one-time decision but a cycle the Bank runs continuously, and improves each turn.

That is the category EPM defines. Not a feature added to the Core, but the Revenue Operating Layer above it, where a Bank’s Revenue Decisions are made, executed, and governed. The Core is where a Bank keeps its accounts. EPM is where it runs its Revenue Business.

‍