SOLUTIONS / Banking

Keep autonomous banking workflows within customer and transaction boundaries

Control agents across accounts, lending, payments, branch operations, and customer service.

Get a demoExplore the workflow ↓
01 / IDENTITY02 / POLICY03 / AUDIT
FABRIQ / RIPPLEIDENTITY · PERMISSIONS · VISIBILITY
Autonomy, with accountability.FABRIQ / BANKING
01 / THE CONTEXT

Prepare the transaction.
Leave the approval to a person.

Banking agents may retrieve account information, investigate transactions, collect loan documents, recommend products, or initiate operational changes. These workflows require precise distinctions between viewing, recommending, initiating, and approving.

TRANSFER INSTRUCTION · EXAMPLETR-90418
Acting identity
banking-agent, for an account manager
From
Assigned account ····3391 in scope
To
Beneficiary ····7742 domestic
Channel
ACH permitted
Amount
Within the limit set for this account manager
INITIATED — NOT APPROVED

Initiating and approving are separate acts. The second one belongs to a person.

02 / IN PRACTICE

Autonomy, with accountability.

ONE INSTRUCTION, FOLLOWED THROUGHIllustrative · banking-agent, acting for an account manager
  1. Prepare a transfer from account ····3391Authenticated customer session · the manager’s own permissions travel with itenters the gateway ↓
  2. 01

    Is the account the one in this session?

    continues ↓
    blocked

    An unrelated customer’s account

    The session sets the boundary. Stopped inside Fabriq — the core is never called.
  3. 02

    Reading, or moving money?

    continues ↓
    allowed

    Read this customer’s balances and recent transactions

    SalesforceAllowed under the manager’s own permissions, recorded with both identities.
  4. 03

    Inside the amount, destination and channel limits?

    continues ↓
    blocked

    A transfer past the ceiling set for this manager

    Limits are read per transaction, so the payment is never prepared, let alone sent.
  5. heldPrepared: ACH to beneficiary ····7742

    Initiation ends here. Release belongs to a second person with the authority to give it — four eyes, kept by the grant rather than by habit.

    RELEASED BY

Example instruction. The sessions, ceilings and release rights are the ones you set.

03 / WHAT CHANGES

Control, in the details.

01

Restrict agents to the authenticated customer and relevant accounts.

The session defines the boundary: the agent serves the customer in front of it and cannot browse the broader book.

02

Separate the accounts and channels an agent can reach from the ones it cannot.

Reach is an action-and-resource grant, so an agent can prepare a payment on an allow-listed account and have no route to any other.

03

Separate payment preparation from payment release.

The release action is left out of every agent’s grant, so the four-eyes principle automation tends to erode holds by construction.

04

Limit lending agents to approved data and permitted decision-support roles.

Lending agents gather, validate, and summarize; credit decisions stay with authorized underwriters and approved models.

05

Keep adverse and exceptional actions in the hands of the people who may take them.

An action adverse to a customer is granted to the staff who hold that authority and to no agent, so it is not in the tool list an agent receives.

06

Preserve the user, the agent, the action, and the verdict behind each call.

Every account action carries its full context, ready for supervisor review or a customer dispute.

THREE LAYERS. ONE DECISION.

The boundary travels with the work.

Explore the context attached to every request.

What is this agent allowed to do?

banking-agent has a defined purpose and a bounded set of tools.

04 / WAYS TO PUT IT TO WORK

Built for your real workflows.

01Customer-service agents with account-specific access.

Access follows the authenticated session, so the agent reads the caller’s accounts and nothing else.

Identify→Authorize→Record
02Loan-origination agents that collect and validate documents without making unauthorized credit decisions.

The agent accelerates the file; the credit decision remains with underwriters, enforced by role rather than convention.

Identify→Authorize→Record
03Fraud-investigation agents restricted to assigned cases.

Per-case access keeps investigations separate and clean, with no bleed between customers under review.

Identify→Authorize→Record
04Treasury and payment agents pinned to allow-listed accounts.

Payment preparation runs on the accounts the desk can reach, and the release action belongs to authorized staff rather than to the agent.

Identify→Authorize→Record
05Branch-assistance agents that operate under the employee’s authority.

The branch employee’s own permissions cap what the assistant can do, teller to manager alike.

Identify→Authorize→Record
QUESTIONS

A closer look.

Can this sit in front of core systems without re-platforming?+

Yes. Fabriq sits between agents and the cores, CRMs, and payment rails you already operate. The systems themselves are untouched; every agent action against them is checked against the agent’s grant and the acting employee’s own authority first.

How is customer isolation enforced?+

Access is tied to the authenticated customer session. The agent reads that customer’s accounts and history for the duration of the interaction, and its reach ends when the session does — there is no standing credential that spans the book.

What evidence exists after an incident?+

One trail across every agent and system: who asked, which agent acted, what it touched, and the verdict — filterable and exportable for your review.

Can limits differ per employee and per customer?+

Yes — both at once. Reach resolves from the acting employee’s authority and the authenticated customer’s session together, so a branch assistant, a payment agent, and a service copilot each operate within exactly the boundaries that pairing allows.

Does sign-in run through our identity provider?+

Yes — Okta and OIDC-compatible providers plug straight in, so bankers use the access they already have and agents operate under those identities.

Can we keep money movement out of an agent’s hands?+

Yes — grant the reads and leave account changes and release out, per employee and per action. What an agent was not granted never appears in the tool list it is handed.

YOUR NEXT CHAPTER

Give banking
room to move.

See Fabriq in action
Policy FirewallEnterprise IdentityAudit Trail