Process Intelligence: Key to Banking Automation

Banks already run intelligent automation across Know Your Customer (KYC) checks, loan origination, anti-money laundering (AML) monitoring, and document processing, yet only 39% of respondents to McKinsey’s “The state of AI in 2025” survey attribute any earnings before interest and taxes (EBIT) impact to AI (McKinsey, 2025).

The stack pairs robotic process automation (RPA) and intelligent document processing (IDP) with machine learning (ML), natural language processing (NLP), and orchestrated agents. The gap sits in the delivery layer, where bots and agents built from process documentation meet the undocumented variants, exception paths, and spreadsheet workarounds that carry real cases across legacy and modern systems.

How intelligent automation is used in banking: The short answer

Banks apply intelligent automation to five recurring processes plus an orchestration layer that ties them together, and each one depends on a different lead technology, with RPA still carrying the system updates and handoffs in many cases.

The mapping follows the banking automation opportunities that recur across retail, commercial, and wholesale operations:

• KYC and client onboarding: IDP extracts identity, ownership, and source-of-wealth data from submitted documents, and RPA keys it into the onboarding portal and the core. NLP tools then draft due-diligence summaries for an analyst to approve.
• AML transaction monitoring: Rules engines raise alerts, ML models score and rank them, and RPA assembles the case file an investigator reviews.
• Loan and mortgage origination: IDP reads bank statements and income documents, decision engines apply credit policy, and RPA boards the approved loan in the origination and servicing systems; commercial lenders are piloting agents that draft credit memos.
• Document-heavy operations: Optical character recognition (OCR) and IDP classify and extract checks, trade finance presentations, and loan packets, with low-confidence results routed to a specialist.
• Payments exceptions and reconciliation: RPA matches transactions across systems and flags breaks, and agents can perform the lookups and routing around each exception.
• Orchestration: Business process management (BPM) engines sequence bots, agents, and human tasks and keep the record of who or what completed each step.

What intelligent automation actually is, and how it differs from RPA

Intelligent automation is a stack of cooperating technologies, and plain RPA is only its execution layer: software that replays deterministic clicks and keystrokes inside the application screens a bank already uses.

First-generation RPA was built to replay the steps a person takes on screen, and it still does that well when the steps never change. The stack adds layers that handle what a scripted bot cannot:

• RPA: Executes rule-based steps across user interfaces and APIs, including legacy screens without connectors.
• IDP and OCR: Classify documents and extract fields, typically returning a confidence score for each value.
• ML: Scores transactions, alerts, and applications against patterns learned from historical outcomes.
• NLP: Reads emails, chat, and free-text fields and drafts summaries or narratives for human sign-off.
• AI agents: Complete multi-step tasks by calling bots, APIs, and documents within defined boundaries.
• BPM orchestration: Sequences the other layers and routes exceptions to people.

The practical difference shows up at the exception.

A plain bot stops when a screen changes or a case follows a path its script does not cover; the stack can classify the document, score the case, and route it, but only if its designers knew that path existed. Each layer depends on an accurate definition of how the work runs today.

Process documentation, standard operating procedures (SOPs), workshops, and interviews describe the intended path. Event logs add what instrumented systems record and still omit manual handoffs and spreadsheet workarounds. They also omit the judgment calls that connect work across applications.

Discovery built only on those inputs misses the operational ground truth that bot developers need before they write a line of workflow.

Buyers usually evaluate process mining, task mining, and process intelligence tools to supply that input. Process mining reaches end-to-end depth only after integration with each system of record, while task mining avoids those integrations but captures individual tasks rather than the end-to-end process. Process intelligence tools form a third buyer category that relies mainly on event logs and SOPs, so none of the three shows the end-to-end path of work that never produces a log entry.

Use cases by bank function: Front, middle, and back office

Intelligent automation in banking concentrates in a small set of use cases, and each sits in a specific office with its own stall point, which is where delivery teams should expect bots to break first. The table places the recurring cases:

Banking automation use cases by office

The three clusters below cover KYC and onboarding alongside AML monitoring. They also examine lending and document-heavy operations, including payments and reconciliation, covering much of the documented volume and many of the variants a delivery team will meet.

KYC, onboarding, and AML monitoring

Automation coverage is broad across KYC and onboarding, as well as AML monitoring, because the work is document- and data-heavy. Analysts receive identity and ownership evidence alongside source-of-wealth documents; they verify and key the data across several systems before screening it.

For wholesale onboarding, analysts receive a request form and collect and read documents at a customer due diligence (CDD) desk. They cannot complete the case when evidence is missing, and they spend additional time re-keying the same entity data into the screening tool and the core.

IDP removes the reading step, and RPA removes the re-keying. NLP drafts the CDD summary, but an exception such as a complex ownership chain still goes to a reviewer. Continuous controls monitoring is designed to compare what the desk does with the approved procedure and flag deviations.

For how this applies inside an AML program, see this analysis of AML program oversight.

In transaction monitoring, rules engines generate alerts, and ML models rank them. RPA assembles the case file, which leaves investigators with triage and narrative writing. An observed baseline of how analysts handle each alert type, including the systems they open and the evidence they copy between them, is the input a bot or agent design needs.

Lending: Loan and mortgage origination, underwriting, and credit risk

Automation shortens loan and mortgage origination at four points: document intake, income and asset verification, underwriting pre-screen, and closing, while the credit decision and its exceptions stay with the underwriter.

A mortgage file arrives with pay stubs and bank statements, along with tax transcripts. A processor reads these documents and keys their data into the loan origination system (LOS); IDP extracts the fields and flags inconsistencies, and verification services replace manual review for income and assets. Pre-screen rules then sort files that meet policy from files that need conditions.

The stall point moves to the conditions themselves: an appraisal variance or an unexplained deposit requires judgment and documents the borrower has not supplied. A self-employment income calculation can require the same review.

Commercial lending follows the same shape with a credit memo instead of a file. Banks are piloting agents that draft the memo from financial statements and prior exposure, and the figures they have published so far are time-saving goals rather than measured outcomes.

On the mortgage side, Rocket, a mortgage lender, reported purchase mortgage cycle time falling from 38 days to 28 days between July 2022 and July 2024 (Rocket, 2024).

Documents, payments, and reconciliation

OCR and IDP carry much of the extraction for checks and trade finance presentations. They also extract loan packets, and the design decision that matters is which confidence threshold sends a result to a person.

Earlier OCR-era tools sent every discrepancy to a person, while newer extraction tools route only low-confidence results to review. The sources reviewed do not support an independent accuracy or straight-through processing (STP) benchmark for letters of credit or checks. Loan-packet benchmarks are also unsupported; vendors define STP and accuracy differently, so compare a vendor’s number only against its own definition.

Payments exceptions and reconciliation stall where a break spans two systems that share no data layer, so an analyst exports both sides to a spreadsheet, matches them, and keys the correction back. RPA handles the matching once the rules are explicit, and an agent can perform the lookups around a break, but a team cannot build either until someone records the spreadsheet step that the documented procedure omits.

Unstructured inputs such as emails, PDFs, images, and handwriting are the reason document automation needs a dedicated extraction layer. The Skan AI partnership with Instabase pairs work observation with Instabase’s generative-AI extraction from unstructured data.

Generative and agentic AI as the next layer

Agents belong on top of the bots a bank already runs, as the layer that decides which bot, API, document, or person to invoke next. Deterministic RPA keeps executing the steps underneath.

NongHyup Bank’s 2025 annual report, cited in the results table below, describes an “RPA Agent” that executes existing RPA bots from natural-language commands and an “Auto Healing” function for screen UI errors. Generative models drafting credit memos, CDD summaries, and investigation narratives sit in the same position: they produce a draft that a bot moves and a person approves.

Process redesign and missing context

Dropping an agent into an unchanged process produces a faster assistant inside a process that stays sequential, a pattern McKinsey’s June 2025 agentic AI report describes for agents embedded in legacy workflows without redesign (McKinsey, 2025).

The second failure is context. An agent grounded in SOPs and event logs lacks the decision logic, escalation rules, and exception handling that live in analysts’ heads, and each of the agentic AI in banking use cases depends on that context before an agent can act.

From observation to operational context

Skan AI is an agentic AI platform powered by a context graph rather than a process mining, task mining, or process intelligence tool. It addresses that input problem by building a Context Graph of Work from desktop-level context capture from process activity.

The graph is a continuously updated property graph that connects people, applications, tasks, decisions, policies, outcomes, relationships, sequences, and governance constraints, and it captures the cross-system handoffs, documented-process gaps, and exception patterns that event logs miss. Where those categories start from event logs, SOPs, or individual tasks, Skan AI’s unit of analysis is observed work across the end-to-end process.

Observation runs through the Skan Virtual Assistant, a lightweight desktop sensor that captures process activity across mainframes, virtual desktop infrastructure (VDI), legacy desktop applications, web applications, spreadsheets, and office tools without backend integration with every application. Email content and keystrokes are never captured.

Skan PRISM, an on-premises privacy gateway, applies pixel-level redaction inside the customer environment so raw screen data remains within the customer-controlled perimeter, a privacy-by-design approach. The resulting model works as a digital twin of operations that stays current as the process drifts.

Skan AI builds a pipeline on the graph that runs from observed work to governed execution:

• Skan AI Intelligence: Converts desktop-level observations into end-to-end process flows, variant analysis, execution metrics, bottleneck detection, and drift detection, so a bot developer sees every path a case took rather than the single path the SOP drew.
• Automation Explorer: Scores each observed task with separate RPA Opportunity Score and Agentic Automation Score outputs; the scoring is vendor-neutral and separates deterministic work from work that needs context, reasoning, or judgment.
• Skan AI Blueprint: Ranks the opportunities by measurable impact and produces an evidence-based roadmap in weeks, not months.
• Agentic operating procedures (AOPs): Encode workflow steps, decision rules, exception handling, policies, escalation thresholds, execution rules, and success criteria as machine-usable representations of observed work.
• Skan AI Agents: Executes tasks within AOPs, with Agent Studio defining scope, permissions, boundaries, escalation paths, and controlled launch conditions, and a governance layer that records inputs, outputs, actions, decisions, and rationales for case-level review.

The observation-to-agent pipeline converts observed work into governed agent behavior with policy controls, evaluation against human baselines, and performance benchmarking before an agent moves to production. A Fortune 100 bank that observed its AML and KYC case handling found that cases deviating from the documented procedure took longer to complete than cases that followed it.

What results do banks actually get?

The results with traceable sources come from bank and lender disclosures, including investor materials and press releases, and they report shorter onboarding, exception, and document-preparation times; none has an independent audit behind it. Each row below measures something different, so read them side by side rather than adding them:

Disclosed intelligent automation results by use case

For a delivery team, the usable benchmark is internal: the cycle time, exception rate, and rework rate of the observed process before any change, then measured again on the same cases after agents are deployed.

How do banks connect automation to legacy core banking systems?

Banks connect automation to core systems through three patterns: user-interface automation, middleware or API layers, and event streaming or change data capture.

The right one depends on whether the core exposes the function and how much change the bank can absorb.

• User-interface automation (screen scraping): A bot drives the 3270 emulator (the terminal software operators use to reach mainframe screens) or the desktop client the way a person does. It needs no API and is typically less expensive and less complex to build than API-based integration, and it breaks when a screen layout, field position, or workflow step changes, because the bot finds each field by its screen position. Shared bot credentials and thin audit trails are its recurring control weaknesses.
• Middleware or API layer: Customer Information Control System (CICS) Transaction Gateway, IBM message queuing (MQ), z/OS Connect (IBM’s API layer for mainframe programs), or a vendor API hub exposes core functions to bots and agents. It costs more to build, and it survives the screen changes that break a bot.
• Event streaming or change data capture (CDC): Replication engines publish core-record changes to topics in Kafka, an open-source event-streaming platform, so downstream automation reacts in near real time. It depends on connector licensing, and connector maturity varies, so the consuming system must handle duplicate events.

Core capabilities and batch constraints

Current releases of the major cores expose APIs and events. Temenos documents REST APIs and a Data Event Streaming API that publishes to Kafka, and Finacle API Connect offers an API Hub and a Kafka-based Event Hub.

FIS exposes its platforms through Code Connect, while the Celent profile it reprints describes IBS and Systematics as COBOL-based batch platforms. Fiserv’s developer documentation shows the Premier transaction API posting entries into a nightly batch file even though Finxact is fully RESTful.

The sources reviewed do not identify a specific legacy release that lacks an API. The constraint a delivery team meets is batch posting, release age, and the cost of exposing each function, and that is why the integration pattern decision belongs to the automation team rather than to the core vendor’s roadmap.

Observation before integration

Observation at the desktop level sits underneath all three patterns rather than replacing any of them.

Screen-level observation records what an operator does in the emulator, the VDI session, and the spreadsheet beside them, regardless of whether the core exposes that function so the bot developer sees the variants, the retries, and the manual reconciliation steps before choosing an integration pattern. Event logs cannot supply that view for work that never produces a log entry.

How do regulators treat AI decisions in lending and AML?

US model risk guidance now excludes generative and agentic AI from its scope, and the EU AI Act treats credit scoring of natural persons as high-risk. Regulation B still requires specific reasons for every adverse credit action, which makes explainability a documentation and control obligation.

US model risk guidance

The Federal Reserve’s SR 26-2, issued April 17, 2026, supersedes the 2011 guidance and states that generative and agentic AI models “are not within the scope of this guidance”, while its principles apply to traditional statistical models and non-generative, non-agentic AI (Federal Reserve, 2026).

The Office of the Comptroller of the Currency (OCC) rescinded its 2011 bulletin the same day and, with the other agencies, plans a request for information on model risk management that considers banks’ AI use (OCC, 2026).

SR 26-2 also supersedes the 2021 interagency statement on model risk management for BSA/AML systems, which leaves AML monitoring models under the same reset. No explicit explainability requirement appears in the retrieved text of either document; validation rigor scales with a model’s approach, use, and materiality. Automation teams should route any model risk classification of a bot or agent through the bank’s model risk and legal functions before go-live.

Under the EU AI Act, Annex III point 5(b) classifies “AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score” as high-risk, with an exception for fraud detection (EUR-Lex, 2026). Regulation (EU) 2026/1744 moved the application date for those stand-alone high-risk systems to 2 December 2027 (EUR-Lex, 2026). A bank deploying such a system must:

• Assign competent oversight: Article 26(1) requires human oversight by people with the “necessary competence, training and authority” and monitoring of the system in operation.
• Keep logs: Article 26(6) requires retaining automatically generated logs for “at least six months”.
• Preserve override: Article 14 requires that overseers can “disregard, override or reverse the output” and interrupt the system.
• Assess rights impact: Article 27 requires a fundamental rights impact assessment before use, and Article 26(11) requires informing the natural persons subject to the system.

For US consumer credit, 12 CFR 1002.9 still governs. Adverse-action reasons “must be specific and indicate the principal reason(s)”, and citing internal standards or a failed score is insufficient (eCFR, 2026). The Consumer Financial Protection Bureau (CFPB) withdrew its 2022 and 2023 circulars on complex algorithms on May 12, 2025, in a notice stating that the withdrawal “is not necessarily final” (Federal Register, 2025), and the regulation’s text is unchanged.

The Sarbanes-Oxley Act (SOX) and the Payment Card Industry Data Security Standard (PCI DSS) apply to bots and agents regardless of the model inside them:

• SOX internal control over financial reporting: SEC Release 33-8810 states that “the proper and consistent operation of automated controls or IT functionality often depends upon effective IT general controls” covering program development, program changes, computer operations, and access to programs and data (SEC, 2007). A bot that posts journal entries is, in our reading, an automated control, and its change management and service-account access fall inside that scope.
• PCI DSS v4.0.1: Requirements 7.2.5 and 8.6.1 through 8.6.3 cover application and system accounts, interactive logins, and hard-coded passwords in scripts, which is where bot credentials live. The PCI Security Standards Council’s 2025 AI principles add that “Use of AI does not remove or bypass the need to meet the requirements of any applicable PCI SSC standard” (PCI SSC, 2025).

Neurosymbolic AI, which combines neural and symbolic approaches, offers a technical answer to model-layer explainability that none of these texts names. In a neurosymbolic design, neural pattern recognition identifies the activity or document feature, and explicit symbolic rules classify it while leaving a reasoning path a validator can examine. The sources reviewed show no regulator mandating that architecture, and it produces evidence a model risk function can review rather than compliance by itself.

Which platforms do banks use, and how do they compare?

The platforms banks most often evaluate include the RPA and orchestration suites below, and the useful comparison for a delivery team is each vendor’s stated banking coverage and its disclosed bank deployments rather than an analyst tier. The entries below are vendor-stated unless noted:

RPA and orchestration platforms by stated banking coverage

When discovery comes from the same vendor that sells the bot runtime, the backlog can end up scored on what that toolchain executes rather than on what the work needs, a risk worth testing during evaluation.

Scoring each task on rule density and judgment requirement before choosing a runtime lets the team send deterministic work to the bot platform it already licenses and judgment-heavy work to an agent framework.

Where not to automate, and why pilots stall

Avoid automating high-risk exception paths like a credit exception, an escalated complaint, or any step whose outcome a regulator or customer can contest. Each needs a decision that a named person can explain and defend.

An exception is by definition the case the policy did not anticipate; an agent can assemble the file and propose a disposition, and the override decision and its reason stay with the underwriter so that override performance can be tracked.

The credit exception is the first case to keep with people. The loan origination guidelines from the European Banking Authority (EBA) call for “control mechanisms, model overrides and escalation procedures” that include “expert judgement and critical analysis” (EBA, 2020).

Complaint handling is the second. The CFPB’s 2023 analysis of chatbots found their effectiveness “wanes as problems become more complex” and documented “doom loops” that occur “without an offramp to a human customer service representative” (CFPB, 2023). Automate the intake, the classification, and the evidence pull; route the decision and the response on any dispute to a person.

Pilots stall for three reasons that recur across the evidence, and all three are process problems before they are technology problems:

• Unknown variants: A peer-reviewed study of RPA processes, most of them in banking, found a strong negative correlation between process variation and bot success rate (Springer, 2024). Teams that build bots only from the documented path expose them to the undocumented ones.
• Governance and cost: Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027 “due to escalating costs, unclear business value or inadequate risk controls” (Gartner, 2025). In our reading, a delivery team running a pilot without a human baseline will struggle to show that value.
• Legacy fragility: The Bank of England and FCA’s 2022 survey of machine learning in UK financial services reported that “The greatest constraint to ML adoption and deployment is legacy systems” (Bank of England, 2022), which is why the integration pattern decision comes before the agent decision.

What does a realistic implementation roadmap look like?

A realistic roadmap observes the process first, proves one automation against a measured baseline, re-engineers before it scales, and treats the operating model and skills as deliverables, with first evidence available within a few weeks.

1. Observe and baseline (within a few weeks): Deploy observation across the target process and capture cycle time, variants, exception paths, cost per case, and the application dependencies behind each step. This replaces shadowing and interviews with the operational ground truth that requirements can be written against.
2. Pilot or minimum viable product (MVP) on one process: Choose a candidate with high rule density and a clear system-of-record write-back, build from the observed variants, and measure the bot or agent on the same cases the baseline used: throughput, exception rate, rework, and accuracy against the human baseline.
3. Re-engineer, then scale: Remove the re-keying and spreadsheet steps the observation exposed before automating them, because an agent added to an unchanged sequence only speeds up the sequence. Add drift detection so an upstream change surfaces before the deployed bot fails in production.
4. Operating model and change management: Assign ownership of the backlog, the scoring criteria, and bot maintenance capacity as soon as step one delivers first evidence in weeks, not months, and train the delivery and business teams on the revised procedures.

The decision in front of a banking operations team is to baseline observed work before choosing a bot, an agent, or an integration pattern. Every automation that follows should then be measured against that baseline, on the same cases, for cycle time, exceptions, and rework.

Request a demo or contact us to discuss how the Skan AI platform can help you baseline and reliably automate your operating environment with agentic.