Why bank data rarely becomes revenue

Why does fragmented data hide revenue opportunities?

A bank may hold extensive information about a customer without having a usable view of that customer's next financial need. The challenge is connecting records that were created for different purposes, updated at different times and owned by different teams.

Core banking systems hold account and transaction records. Customer relationship management systems capture contacts and conversations. Loan origination systems support applications, while loan management systems track existing facilities. Treasury tools, spreadsheets and external sources add further context. Each can contain a useful part of the story.

The gaps appear between those parts. A relationship manager may know a customer is opening another location, while a credit team sees increasing utilization and a treasury team sees changing payment volumes. Without a shared view, each observation can look routine. Together, they may justify a timely conversation.

Three practical problems make the connection difficult:

• Identity: records may refer to a parent company, subsidiary, trading name or individual contact without clearly linking them.
• Timing: a current balance, an older financial statement and a recent conversation describe different moments.
• Meaning: a field such as “active” or “approved” may represent different states in different systems.

Combining records without resolving these differences can produce a confident but misleading recommendation. Revenue teams need the context behind a signal, including what remains unknown.

What makes a customer signal useful?

A useful signal changes the reason to contact a customer. It should be relevant to a possible need, recent enough for the proposed action and supported by information the bank can inspect. A large change is not automatically a commercial opportunity.

For example, a rising deposit balance might reflect business growth, seasonal receipts, a temporary transfer or money already committed to an upcoming payment. Credit utilization might indicate expanding demand or financial pressure. The same observation can support different explanations, with different implications for the next conversation.

Separate three layers in every recommendation:

1. Observation: what the source actually shows, with an entity and a date.
2. Interpretation: what that observation might mean for the customer's needs.
3. Validation: what a banker or customer must confirm before the opportunity proceeds.

External information can add context, but it needs the same discipline. A hiring announcement or new contract should be matched to the correct business and checked for relevance. Public visibility does not establish the bank's permission to use every piece of information for every purpose.

Preserve the source and observation date so a reviewer can challenge the interpretation. If the evidence is weak, the next task may be clarification rather than a product offer.

Three examples of signals worth connecting

The following fictional examples illustrate possible conversations. They are not customer results, product eligibility assessments or evidence that a particular signal predicts revenue.

Business growth and working capital

A distributor announces a new supply contract. Its existing credit facility is being used more heavily, and its relationship manager has recorded longer customer payment terms. Together, the records suggest a possible timing gap between paying suppliers and collecting receivables.

The next step is to confirm the operating cycle, contract timing and existing funding arrangements. Additional credit may be relevant, but the customer may already have sufficient financing or may need a different solution. The evidence earns a conversation; the conversation determines whether there is an opportunity.

Changing cash balances and treasury needs

A business shows larger swings in balances across its accounts while payment activity increases. Separately, an account team learns that finance staff are spending more time moving funds and reconciling transactions. The combined context suggests a discussion about cash visibility and treasury operations.

Before proposing a service, establish how the customer currently manages liquidity, what is manual and which problems matter to the finance team. The bank should also check existing services so it does not recommend something the customer already uses.

A new location and an existing relationship

A customer announces plans to open another location. Internal records show the current relationship, existing facilities and the appropriate contact. A recent conversation may reveal whether the opening is funded and when operations are expected to begin.

That context can support a discussion about payments, deposits, equipment financing or working capital. The useful action depends on the customer's actual plan. Sending separate offers from several teams before confirming the need can turn a relevant signal into a fragmented customer experience.

What should an actionable opportunity contain?

A useful opportunity record answers who to contact, what need to explore and why the timing matters. It also makes uncertainty and ownership visible. A label such as “high cross-sell potential” gives the next person too little information to act responsibly.

Use a brief with six elements:

• Customer and relationship: the matched entity, existing products, contact and relationship owner.
• Possible need: a specific customer objective the bank can help investigate.
• Supporting evidence: relevant records, sources and dates, with conflicting information identified.
• Open questions: the facts that could confirm or disprove the interpretation.
• Next action: a defined task, owner and expected response time.
• Disposition: how the team records progress, deferral, rejection or completion.

Prioritize using more than estimated deal size. Consider evidence quality, timing, customer relevance and the team's capacity to follow through. A smaller opportunity with a confirmed need may deserve attention before a larger one built on several untested assumptions.

Make the reasoning readable. A banker should be able to explain why an opportunity is in the queue and what new information would change its priority. That is more useful than a score without supporting context.

When should a signal leave the queue?

Remove or defer a recommendation when new information invalidates its premise. The business may already have addressed the need, the announced event may be delayed, or a similar conversation may be active with another banker. Keeping these cases in the queue inflates pipeline counts and consumes attention.

Use a documented reason and, where appropriate, a future review date. A deferred opportunity should return because relevant circumstances changed or the customer requested another conversation. This gives the team a more useful memory than repeatedly rediscovering the same signal.

Why isn't a better dashboard enough?

A dashboard can show a pattern and help a banker choose where to focus. Commercial progress still depends on what happens after someone sees it. The customer must be contacted, the need confirmed, the appropriate information gathered and any required decisions completed.

Without an assigned owner, an opportunity can stay visible while remaining untouched. Without a next action, it can sit in a pipeline after an initial call. Without a shared status, one team can continue outreach while another is already handling the same request.

The solution is to connect the opportunity record to a workflow with explicit completion conditions. A customer who declines should leave the active queue. A case waiting for documents should show exactly what is missing. A decision awaiting review should identify the reviewer and the question they need to resolve.

FORFI's approach to autonomous revenue execution connects opportunity identification with this follow-through. Its six stages cover outreach, qualification, documents, approvals, system updates and monitoring, while the bank retains decision authority. Read the detailed guide to autonomous revenue workflows in banking for the responsibilities and outputs at each stage.

How can a bank start closing the gap?

Start with a commercial question specific enough to test. For example: which existing business customers may have a working capital need that warrants a conversation? Agree on the customer group, participating teams and evidence needed to make that recommendation.

Map the minimum records needed for that use case. Identify where they live, who owns them, how frequently they change and how customer identities are matched. This creates a bounded project while exposing the data problems that matter to the actual decision.

Check a sample with the relationship managers who know those customers. Ask whether the facts are correct, the proposed need is plausible and the timing is useful. Record why a recommendation fails: wrong entity, stale information, existing solution, no customer need or missing context. Those reasons help improve the next iteration.

Banking has a long-standing focus on dependable data aggregation. The Basel Committee's principles for effective risk data aggregation and risk reporting address weaknesses in combining risk information fully, quickly and accurately. Their purpose is risk management; applying similar care to commercial signals is an operational recommendation here, not a claim that revenue workflows fall within that framework's scope.

Before customer activity begins, agree on access, permitted uses, review responsibilities and how sensitive information is handled. Define how corrections reach the source record and how unresolved identity conflicts are escalated. Connecting data should make discrepancies easier to resolve, rather than spreading them into more systems.

Finally, assign a workflow owner and a review cadence. The owner should see stalled cases and recurring data problems together. Otherwise, a team may keep improving detection while a separate execution problem remains untouched.

How do you measure whether connected data creates value?

Measure the full path from signal to outcome. A larger list of recommendations can reflect broader detection, weaker filtering or duplicate cases. It does not establish that customers received more relevant help or that the bank earned incremental revenue.

Begin with evidence quality. Sample recommendations to check entity matching, freshness, source availability and whether the proposed need survives banker review. Then follow the commercial funnel: accepted opportunities, customer responses, qualified needs, completed applications or service requests, and final outcomes.

Use clear denominators. “Qualification rate” could mean qualified cases divided by all recommendations, by contacted customers or by respondents. Choose the definition before the pilot and keep it consistent. Record elapsed time and abandonment reasons alongside conversion so the team can explain changes.

Distinguish the size of a transaction from revenue. A loan principal amount, deposit balance or projected pipeline value is not recognized revenue. Finance should define the revenue measure, observation period, attribution method and relevant costs before results are presented as a return on investment.

A comparison group or phased introduction can help separate workflow effects from seasonality, existing pipeline and changes in customer demand. Where a credible comparison is unavailable, describe the observed results and their limits instead of assuming every completed transaction was incremental.

Include the cost of reviewing recommendations, correcting records and completing customer work. Review a sample of rejected recommendations as well: overly narrow filtering can hide legitimate needs. Evaluating both accepted and rejected cases helps the bank improve relevance without treating a smaller queue as automatic evidence of better quality.

The goal is a repeatable connection between evidence, a useful action and an outcome the bank can verify. Start there, then expand the customer group or use case as the data and execution process become reliable.