Why Banks Lack Application Usage Visibility and What It Costs Them

Most banks cannot see how a case moves across the applications their staff use to manage and complete it, and that blind spot hides accumulating cost every day. A 10-year analysis of bank IT spending from McKinsey found that applications per $1 billion of revenue rose from 133 in 2013 to 224 in 2022, “a jump of more than 68 percent” (McKinsey, 2022). Event logs record what happens inside each of those applications; nothing records the handoffs and re-keying, including spreadsheet workarounds between them, so the processing time and unit cost they add stay off every report.

What application usage visibility means in banking

Application usage visibility in banking is a continuous, auditable view of which applications are in use, by which human and non-human identities, how often, and with what data. Each clause in that definition matters, because the data sources banks already own answer only one or two of them.

The usual inputs each cover a slice:

• Single sign-on and identity provider logs: These record who authenticated to which application and when, but not what the person did after login.
• API and session telemetry: These capture calls and sessions inside instrumented applications, so they cover modern systems with structured interfaces and skip everything else.
• Application performance monitoring agents: These report response times, errors, and resource use for the applications they are installed on, from the infrastructure side rather than the user’s side.
• Cloud access security broker and SaaS discovery tools: These match network traffic against an application catalog to find sanctioned and unsanctioned cloud services, and they see nothing that does not cross the network.
• In-app analytics: These show feature use inside one application, with no view of the application opened before or after it.

A bank that stitches all five together still has no record of the moment a Know Your Customer (KYC) analyst copies a value from a mainframe screen into a spreadsheet and then into a case management tool. That moment is where processing time accumulates.

The three meanings banks use interchangeably

“Application visibility” means three different programs inside a bank, and a tool built for one meaning will not meet requirements written for another. The three deserve separate labels.

• Internal employee and SaaS usage governance: Which applications staff use to do operational work, how much of each case passes through each one, and which licenses sit idle.
• Customer-facing application analytics: How customers behave inside mobile and online banking, including session paths, drop-offs, and fraud signals.
• Infrastructure-level application performance monitoring: Whether the applications themselves are up, fast, and error-free from the data center outward.

Heads of operations and shared services leaders almost always need the first meaning, extended from the SaaS layer down to the desktop where mainframe sessions, VDI windows, and spreadsheets live. Transformation officers share that need. The other two belong to the fraud team and to IT.

Why banks can’t see what’s actually happening

Banks cannot see how work happens because event logs stop at the edge of each system, while standard monitoring agents skip mainframe and legacy screens. Survey-based usage data also arrives late and relies on self-reporting. Adding connectors to more systems cannot capture work that produces no event, runs through a rendered remote screen, or exists only in an employee’s recollection.

System logs only capture events inside their own system

A loan origination system records milestones: application received, conditions issued, clear to close. It records nothing about the processor who emailed a borrower for a missing paystub, the underwriter who toggled between the origination system and a spreadsheet to calculate debt-to-income on a non-QM exception, or the closer who re-keyed figures into a title portal. Those steps are the cycle-time drivers, and they produce no event in any system of record.

Log-based process mining inherits this limit by design. It reconstructs a process from timestamps inside connected systems, so the work between systems appears as an unexplained gap between two events. Gartner’s 2023 Digital Worker Survey found that 47% of digital workers struggle to find the information needed to effectively perform their jobs (Gartner, 2023); a single case spans several applications, so a log from any one of them explains only a fraction of the case.

Mainframe and legacy activity sits outside standard monitoring tools

Where core banking, deposits, or card servicing run on mainframes, staff reach them through terminal emulators or Citrix and VDI sessions. A VDI session delivers a rendered screen to the endpoint while the application runs elsewhere, so an endpoint agent that inspects local processes or network connections sees a display stream rather than an application. Log-based mining tools reach these systems only through custom connectors, exports, or RPA bots that pull data out.

The SaaS management and CASB platforms covered later in this article document discovery through identity providers, browser extensions, network logs, and expense data. Their published documentation does not describe mainframe, Citrix, or VDI coverage, which leaves the systems that carry the most transaction volume outside the usage picture.

Survey-based usage data is self-reported, delayed, and unreliable

Consulting diagnostics and internal time studies ask staff how they work, or observe a sample of them for a few days. Respondents are likely to describe the documented procedure rather than the exception path they took on the last complex file, and a time study can easily miss the week when volume spikes and shortcuts begin. By the time the findings reach a steering committee, the process has changed again.

An automation business case built on that kind of baseline can miss the exception paths that break a bot in production.

What poor visibility costs a bank

Poor visibility raises processing time first and unit cost next; at scale, those increases raise annual run cost because each unobserved application switch can add minutes that rarely appear in a budget. The arithmetic does not depend on a bank-specific benchmark.

Start with a single case, say a beneficiary change or a KYC refresh. Each application the operator opens adds a context switch and re-orientation, often followed by a re-keyed value; a controlled experiment by Bailey and Konstan found interrupted tasks took 3–27% more time and produced twice the errors (Bailey & Konstan, 2006). Errors force operators to perform rework and make a second pass through the same applications.

Operators add those minutes to handle time, and finance converts handle time through loaded labor cost into cost per case. When a shared services center handles thousands of cases each month, the hidden switching cost becomes material even though no system logged it. Case studies from banking and wealth management report these results:

• Beneficiary maintenance at a Fortune 100 wealth management institution: $30 million in immediate savings, with $250 million in potential savings identified over three years.
• Utilization improvements at a Fortune 250 P&C carrier: $12.4 million in annual savings.
• Case processing cost: One client recorded a cost reduction of more than 35% in case processing time.

The visibility gaps that leak money: shadow IT, service accounts and API keys

Departmental SaaS purchases create one visibility gap; service accounts and API keys create another. Each can use bank systems while remaining absent from the usage reports that operations leaders review, and regulators have started naming these gaps directly.

Business units buy their own software. HFS Research’s BFSI Pulse found 54% of technology-related spend under IT control and 46% outside it, across 605 respondents (HFS Research, 2024). The FFIEC defines shadow IT as devices, software, or services operating “without the knowledge, approval, or control of IT management” (FFIEC, 2021), and the OCC’s cybersecurity supervision work program says that “security awareness or information security training should include procedures for identifying and reporting shadow IT” (OCC).

Off-channel messaging provides a regulatory-cost analog for applications used outside approved governance. The SEC states that since fiscal year 2022 it has brought 95 actions and $2.3 billion in penalties against firms that failed to preserve off-channel communications (SEC, 2026). Those cases concern messaging applications used outside approved channels, a close analog to shadow IT as the FFIEC defines it.

Non-human identities form the second gap. Gartner’s survey of 335 identity and access management (IAM) leaders found identity teams responsible for only 44% of machine identities (Gartner, 2025), which leaves most machine identities outside the IAM team’s responsibility. OCC Bulletin 2021-36 asks institutions to identify all users, “including employees, service accounts, and users at third parties”, and to ensure service accounts are inventoried with assigned management responsibility (OCC, 2021).

An operations leader inherits the consequence. A service account that moves files between a loan origination system and a document repository is part of the process; when its credential expires or its permissions drift, the case stalls in a way no human user can explain.

Which applications a bank should be watching

A bank’s visibility scope should cover every application a case touches between intake and completion, which in practice means nine application types spanning modern SaaS and legacy mainframe screens. The scope must also include the spreadsheets between them. Leaving one type out can break the chain, because a case that disappears into an unobserved application returns with no record of the time it spent there.

The nine types a banking visibility program should include:

• Core banking systems: Account, deposit, and transaction records that staff read from or write to while processing most cases.
• CRM and customer service tools: The record of customer contact that explains why a case was opened and what staff promised.
• Email and messaging platforms: Where requests arrive, staff chase conditions, and managers give approvals informally.
• Legacy mainframe applications: Terminal sessions that carry high-volume servicing work and produce no desktop-readable event log.
• Web-based tools: Credit bureaus, title portals, regulator sites, and internal intranet forms.
• Loan origination platforms: The milestone record for lending, with the cross-application work between milestones left unrecorded.
• Compliance and risk management systems: KYC, AML, and sanctions screening tools where analysts wait for a decision.
• Spreadsheets: The universal workaround for calculations, reconciliations, and queues the systems of record do not support.
• VDI environments: The remote sessions through which staff reach many of the applications above.

A scope that stops at the SaaS layer covers the first, second, and fifth items. Staff cannot account for the cycle time spent in the other six.

What a bank should actually measure

A bank should measure six things about application usage, and each metric should map to a decision an operations leader can take, or it is reporting rather than visibility. The metrics below come from both the infrastructure and operations sides. The last two carry the most weight for a cost case.

Operational metrics for application usage in enterprise banks

• Active users (DAU and MAU): Tells you how many people open an application in a day or a month, and how that compares with the licensed count. Drives which licenses to cut, consolidate, or renegotiate.
• Feature adoption: Tells you which functions of an application staff use and which they bypass with a spreadsheet. Drives where training or configuration would remove a workaround.
• Error rate: Tells you how often an application returns a failure or an operator reworks a step. Drives where to direct defect fixes and process redesign.
• 95th percentile (p95) latency: Tells you the response time the slowest 5% of interactions experience. Drives whether an application is the bottleneck or the people are waiting on it.
• License utilization waste: Tells you paid seats with no observed use over a defined window. Drives immediate savings in the next renewal cycle.
• Cost per case: Tells you observed handle time across all applications a case touches, multiplied by loaded labor cost. Drives which process to automate, standardize, or staff differently.

Cost per case is the metric that connects the others to the P&L. It requires observed handle time across applications, which system timestamps and headcount ratios cannot supply. For example, a file that took 45 minutes of touch time and one that consumed three hours of rework across five applications look identical in a milestone log.

Fraud and account takeover: What session-level visibility catches

Session-level visibility on customer channels catches account takeover and fraudulent transfers in progress, and it is a different telemetry stream from the internal application usage visibility this article has described so far. Banks should run both and should not expect one to supply the other.

Customer session telemetry covers the mobile app and online banking, as well as automated clearing house (ACH) origination and wire initiation. Fraud platforms in this category build a continuous record of a session from pre-login reconnaissance through the transaction, across web, mobile, and API channels. They apply behavioral signals such as touch, mouse, and keyboard patterns alongside device and malware checks. The concrete outcome is a wire or ACH transfer held before execution because the session behaved like a bot or a remote-access tool rather than the customer.

Authentication controls sit at the boundary between the customer session stream and the internal usage stream: on customer channels, risk-based authentication can use the same session signals to decide when to step a login or transfer up to multi-factor authentication (MFA), which makes the telemetry both a fraud signal and the source of the friction a genuine customer meets. Inside the bank, the FTC Safeguards Rule, covered in the regulations section later in this article, also requires MFA for any individual accessing any information system at the non-bank financial institutions it covers, yet an MFA event records that an operator authenticated to an application, not what the case required after login. Each additional authentication prompt across the applications a case touches may add a step to handle time that no milestone log captures.

On the infrastructure side, p95 latency on the online banking login path can help an operations center see an outage forming before customers report it.

Published documentation for fraud session platforms does not describe internal employee application visibility. A bank that buys session fraud tooling has protected its customer channels; its KYC analysts’ desktops remain as opaque as before.

Which regulations require usage monitoring

No banking regulation mandates general monitoring of employee application usage, but six frameworks expect logging, inventories, and user-activity records that a bank struggles to produce without application-level visibility. The table maps each requirement to the capability it implies.

Regulatory requirements mapped to visibility capabilities in banking

• FFIEC Architecture, Infrastructure, and Operations booklet (June 30, 2021): Requires log management policies covering log types, review timing, retention, and anomaly escalation (VI.B.7); an accurate software inventory with licenses and users (III.B.1(b)); detection of shadow IT (III.B.3). Maps to application inventory reconciled against observed use and shadow IT discovery.
• OCC Bulletin 2023-17, Interagency Guidance on Third-Party Relationships (June 6, 2023): Requires risk management for “any business arrangement between a banking organization and another entity, by contract or otherwise”, with a complete inventory of relationships. Maps to discovery of employee-adopted SaaS that meets the relationship definition.
• GLBA Safeguards Rule, 16 CFR § 314.4(c)(8): Requires controls “designed to monitor and log the activity of authorized users and detect unauthorized access or use of, or tampering with, customer information”. Maps to user-activity logging on systems holding customer information.
• SOX, Section 802: Requires retention of audit workpapers; no retention period for a company’s application usage logs appears in the primary text. Can support an auditable record of controls over financial reporting systems.
• PCI DSS v4.0.1, Requirement 10: Requires audit logs of all individual user access to cardholder data; automated log review mechanisms from March 31, 2025; 12 months of log history with three months immediately available. Maps to access logging and retention within the cardholder data environment.
• DORA, Regulation (EU) 2022/2554, applying from January 17, 2025: Requires continuous monitoring of ICT systems (Art. 9(1)); mechanisms to detect anomalous activities (Art. 10(1)); sufficient resources to monitor user activity (Art. 10(3)). Maps to documented logging procedures and user-activity monitoring for critical functions.

Scope limits matter when a bank reads this table:

• PCI Requirement 10 applies to systems in or connected to the cardholder data environment, and the PCI SSC’s log monitoring guidance states that out-of-scope systems “are not expected to be monitored”.
• The FTC Safeguards Rule covers non-bank financial institutions under FTC jurisdiction. Banks supervised by the OCC, FDIC, or Federal Reserve follow the interagency security guidelines, which require monitoring for attacks and intrusions but use less prescriptive language about authorized-user activity.

Two of these frameworks are moving. The OCC, FDIC, Federal Reserve, and NCUA proposed replacement third-party guidance on September 11, 2026, with comments due November 16, 2026, and the 2023 guidance remains in effect until finalization. DORA’s logging detail sits in Delegated Regulation 2024/1774, Article 12, which leaves the retention period to each entity’s risk assessment.

Seeing how staff use AI tools like Copilot and ChatGPT with bank data

Employee use of generative AI tools is the newest visibility surface, and banks need to determine which workflows route customer or proprietary data through Copilot, ChatGPT, or a personal account on either.

Gartner’s survey of 302 cybersecurity leaders found 69% suspect or have evidence that employees use prohibited public generative AI tools (Gartner, 2025). FINRA’s 2025 oversight report asked whether cyber programs consider “leakage of customer PII and the firm’s proprietary information entered into prompts by employees”, and its 2026 report describes monitoring practices that include storing prompt and output logs and tracking model version and timing (FINRA, 2026). The OCC’s revised model risk guidance, Bulletin 2026-13, places generative and agentic AI outside its scope, so banks cannot rely on that guidance for this surface (OCC, 2026).

A CASB or SaaS discovery tool identifies which generative AI (GenAI) domains staff reach. Application-level observation of the work itself shows which process step routes into a GenAI tool and which application was open before it. That context can show an operations leader that underwriters paste income documents into a chatbot during condition clearing, for example. Neither method needs to capture prompt text; the process context is what the bank must govern, and the prompt content is what it should not store.

Tool landscape compared

The visibility tools banks already own fall into three categories, and the SaaS management and CASB vendors’ published documentation does not describe observing a case as it crosses mainframe, VDI, and desktop applications. The comparison below uses each vendor’s own pricing and deployment documentation as published; where a figure was not published, the table says so.

Visibility tool categories, licensing models, and documented deployment timelines

• Dynatrace (application performance monitoring): Observes infrastructure, application, and real-user performance. Licensing: annual platform subscription consumed against a published rate card, typically one to three year terms. Deployment: a vendor-commissioned Forrester TEI reports months for initial coverage (Forrester, 2026).
• Datadog (application performance monitoring): Observes infrastructure and application traces. Licensing: per-host per month, annual or month-to-month list pricing. Deployment: the vendor does not publish a timeline in the retrieved material.
• AppDynamics (application performance monitoring): Observes application and infrastructure performance. Licensing: per-vCPU per month, infrastructure-based licensing; SaaS or on-premises. Deployment: a vendor-commissioned Forrester TEI models a phased rollout over multiple years.
• IBM Instana (application performance monitoring): Observes hybrid cloud and application observability. Licensing: usage-based per MVS hour, SaaS or self-hosted, 10-host minimum. Deployment: a vendor-commissioned Forrester TEI reports months for initial implementation at one bank (Forrester, 2024).
• Microsoft Defender for Cloud Apps (SaaS management and CASB): Observes cloud application discovery from network logs against a catalog of 31,000+ apps; session policies. Licensing: standalone or bundled in Microsoft 365 E5 and EMS E5; Microsoft publishes no standalone price. Deployment: Microsoft publishes no timeline; timing depends on log collector and endpoint integration setup.
• Zylo (SaaS management): Observes SaaS spend and inventory from ERP, accounts payable, and expense data. Licensing: Core, Premium, and Enterprise plans; Zylo publishes no prices. Deployment: Zylo does not publish a timeline.
• Torii (SaaS management): Observes SaaS discovery through identity providers, browser extension, desktop agents, and expenses. Licensing: quote-based; Torii publishes no public tiers. Deployment: Torii does not publish a timeline.
• Cleafy (fraud session visibility): Observes customer session record across web, mobile, and API channels. Licensing: Cleafy does not publish licensing details in the retrieved material. Deployment: mobile SDK plus a clientless API gateway plugin; Cleafy does not publish a duration.

The limits each category documents about itself are instructive. Microsoft states that apps not in its catalog are not discovered by default (Microsoft), Zylo’s own guidance describes single sign-on as “only a proxy for usage” (Zylo), and Torii notes that usage is missing for locally installed apps without a desktop agent (Torii). A bank evaluating these tools for operational visibility should ask each vendor one question: show me a KYC case moving from a mainframe screen to a spreadsheet to a case management tool, with the time spent in each.

Privacy limits: What banks should not log

A bank should not log email content, keystrokes, prompt text, or any record that profiles an individual rather than a process, because European regulators treat blanket activity monitoring as disproportionate and U.S. rules do not require it. Visibility programs that ignore this limit stall in works-council review or data protection impact assessment.

The Article 29 Working Party’s opinion on data processing at work lists “tracking of application and device usage” among monitoring technologies, states that “monitoring every online activity of the employees is a disproportionate response”, and says consent “is highly unlikely to be a legal basis for data processing at work” (Article 29 Working Party, 2017). GDPR Article 35 requires a data protection impact assessment before systematic evaluation of personal aspects, and Article 88 lets Member States set stricter employee-data rules through law or collective agreements.

Works-council rights differ by country:

• Germany and the Netherlands provide co-determination or consent rights. German BetrVG § 87(1) no. 6 gives co-determination over technical devices suited to monitoring behaviour or performance (Gesetze im Internet, BetrVG § 87), and the Federal Labour Court held in 2022 that introducing Microsoft Office 365 falls within it (BAG, 2022). The Dutch WOR Article 27(1) requires works-council consent for arrangements that can observe attendance, behaviour, or performance.
• France provides consultation rights. France’s Code du travail L2312-38 requires information and consultation of the works council before monitoring tools are implemented.

Retention windows diverge by scope. PCI DSS requires 12 months of audit log history for the cardholder data environment, while CNIL guidance says internet connection logs should not be kept more than six months (CNIL), and DORA leaves the period to the entity’s risk assessment. U.S. legal obligations alone do not supply a GDPR legal-obligation basis for processing EU employee data, according to Working Party opinion WP217; an EU obligation such as DORA can.

The operational position that satisfies all of this keeps the unit of analysis on the work. Observe which applications a case passed through, how long each step took, and where it stalled; pseudonymize the operator, redact customer data before it leaves the endpoint, set a retention period tied to the business purpose, and put the design to employee representatives before deployment rather than after.

How to get visibility without an IT integration project

A bank can gain application usage visibility from desktop-level process observation without backend connectors or application changes. Teams can deploy the approach without system downtime, so the evidence arrives in weeks, not months. The approach observes work at the point where a person interacts with the screen, which is the one layer shared by mainframe sessions, VDI windows, web tools, and spreadsheets.

Skan AI builds this as a Context Graph of Work: a continuously updated graph that connects people, applications, tasks, decisions, policies, and outcomes from observed process activity. A lightweight agent on the desktop observes process activity across mainframes, VDI, legacy desktop applications, web applications, spreadsheets, and office tools without a backend integration for each one. The result is a digital twin of operations, in the descriptive sense, that shows every application a case touched and the handle time in each, including the handoffs that event logs record as empty gaps.

Operations teams can use the observed evidence for process measurement and privacy controls:

• Process measurement: Operations teams use Skan AI Intelligence to convert those observations into end-to-end process flows, variant analysis, and execution metrics such as processing time and cost per case. They can also identify bottlenecks and drift. For a bank, that is the operational ground truth behind the cost math in this article: observed handle time per case across all nine application types, rather than milestone timestamps and headcount ratios. McKinsey’s “State of AI 2025” found that only 6% of companies report meaningful EBIT impact from AI investments (McKinsey, 2025). A program cannot prove it moved cost per case without knowing what cost per case was.
• Privacy controls: Teams use Skan PRISM as an on-premises privacy and information security gateway that applies pixel-level redaction before protected information can leave the customer environment. Raw screen data remains inside the customer-controlled perimeter, and email content and keystrokes are never captured. Customer-hosted deployment supports data residency requirements in regulated environments, which supports the GDPR and works-council reviews described above.

Operations teams can apply the same observed evidence to application portfolio rationalization. Once a bank can see which applications carry case work, which ones staff open only to copy a value out of, and which licensed seats show no observed use, it can retire, consolidate, and renegotiate against evidence instead of survey counts. The banking operations evidence that supports those decisions comes from the same deployment that measures cost per case, so the visibility program and the rationalization program share one observation layer.