Typewise for banking

AI assistance in banking service: separate workflows and authority

Candidate assistance workflows inside an authenticated scope. Execution, advice and permission decisions stay with your people.

This page describes a deliberately narrow scope of candidate designs. It makes no claim about regulatory compliance and is not legal advice; your compliance, risk and procurement owners decide what may go live and when.

In banking, the question that decides the scope of any customer-service AI is whether the bank knows who it is talking to. Identity-sensitive use cases belong inside an authenticated channel; everything else is general information. The second question is maturity: assisting a person with a summary or a routing decision is a different thing from executing a process end to end, and the two should not be approved together.

The scope below is assist-first. It also takes seriously that the gating factor can be the internal implementation of regulatory requirements rather than the technology: a solution that works in simulation is not live until that gate is passed. Typewise agents read and write in connected CRM, ERP and ITSM systems, sensitive actions wait for approval, hand-offs carry the full context, and every action is logged. Whether any workflow below can run end to end in your organisation depends on what your systems expose and on the data behind them, so each is presented as a candidate design to evaluate, with what it needs, not as a promised capability.

Candidate workflows to evaluate

Assistance workflows to evaluate

General information outside the account

Candidate design

Answer process and product questions anyone may ask, without any account context.

What it needs from your systems

Approved public information sources with an owner.

What stays with people

No account data in an unauthenticated channel, enforced by the systems that hold it.

Intent capture and routing

Candidate design

Ask the customer to say in a sentence why they are contacting the bank and route the request to the right team or partner, avoiding unnecessary first-line transfers.

What it needs from your systems

Routing categories, service levels and destinations defined by the bank; the channel connected for the written or spoken intake in scope. Routing prompts, flows and data sources still have to be built and evaluated even on a no-code platform.

What stays with people

Routing is the decision; the design gives no financial advice on the way.

Written conversation summaries for advisers

Candidate design

Summarise a written thread for the adviser who acts on it, and show what the system understood so staff can trust and correct it.

What it needs from your systems

The written channel connected; voice channels and call transcription are a separate evaluation with their own requirements and are not assumed here.

What stays with people

Summaries assist the person who acts; they are not records of decisions.

Service drafts in the authenticated channel

Candidate design

Prepare replies to routine service requests for verified customers, for a person to check and send.

What it needs from your systems

An authenticated channel where your systems verify the customer; read access to the data the reply depends on, agreed with your security owners.

What stays with people

End-to-end execution of account processes is a separate maturity step with its own approval, not an extension of drafting.

Operating boundaries

What the bank keeps

  • Identity is verified by your systems, not asserted in the conversation: account data and account changes require an authenticated customer.
  • Every action the AI may take is granted per action as read, recommend, draft or execute, and enforced where the action happens, not only in the instructions.
  • Sensitive actions wait for a named approver; hand-offs carry the full context to a person who owns the next step, including outside service hours.
  • Every step is logged, so your team can audit what was looked up, what was proposed and what was done.
  • Advice, account execution and anything with legal effect stay with people; assist-level scope does not grow into execution without a separate decision.
  • Organisational permission is its own gate: technical readiness, internal regulatory implementation and procurement are three different approvals.
How it is enforced

Permissions, approvals and an audit trail.

Agents read and write only in the systems and scopes you connect. Sensitive actions wait for approval, hand-offs carry the full context, and every action is logged. Hosting, access control and certifications are described on the security page.

Security and compliance →See how it works →
Rollout considerations

What a rollout has to take into account.

  1. Step 1

    Decide the authenticated scope first

    Which use cases require a verified customer, and where that verification happens, is the first design decision, not an integration detail.

  2. Step 2

    Start with assist, not execute

    Intent routing, written summaries and reviewed drafts can create value while the organisation decides what end-to-end processing it will permit.

  3. Step 3

    Free capacity with a destination

    Service automation only releases adviser time if service teams first gain room to absorb administration; name where the freed capacity goes.

  4. Step 4

    Plan the permission gate honestly

    Built and tested is not live. Put the internal regulatory implementation and the procurement path in the plan with their real lead times, and expect no-code configuration to still leave flows, prompts and data sources to build.

Good questions. Straight answers.

Not within the scope on this page. The candidate designs assist: general information, intent routing, written summaries and drafts a person checks. End-to-end execution is a separate maturity step with its own approval.

Identity-sensitive use cases live inside an authenticated channel where your systems verify the customer. The AI never acts on an identity claimed in a conversation.

The internal implementation of regulatory requirements and procurement can take longer than the technology. Plan those gates with their real lead times from the start.

Discuss an assist-first scope.

Book a demo and we’ll walk through the authenticated boundary, these candidate assist-level workflows and the permission gates with your risk and IT owners.