Financial services
Clear the queue with every step on record.
Agents, data platforms and migrations on Google Cloud for banks, insurers and payment firms. A person makes every decision about a customer.
Agent workspace · KYC files
An illustration of an agent we build
Queue
- KYC · personalApproved
- KYC · LLCPreparing
- KYC · trustWaiting
- KYC · partnershipWaiting
KYC · personal
ApprovedReads
- ID documents
- KYC policy
- Screening results
The agent prepares
- Reads the documents
- Checks your policy
- Lists the gaps
Ready for review, with every fact linked to where it came from.
A person decides
Analyst approves
File approved
- Google Cloud Partner
- Databricks Partner
100+
Projects delivered
45+
Enterprise clients
8
Industries served
98%
Client satisfaction
What we build
Clear the files that pile up first.
Pick a workflow and watch it run, from the documents it reads to the person who makes the decision.
KYC and onboarding files
KYC analysts and onboarding teams
Assembles the file and lists every gap and mismatch, so the analyst starts from a finished file.
Reads
- ID and entity documents
- Your KYC policy
- Screening results
The agent prepares · Gemini Enterprise
- Reads each document
- Checks it against your policy
- Lists gaps and mismatches
Hands over · KYC file
- Documents read · ID, proof of address
- Policy checks · 8 checks, 1 flag
- Gaps, mismatches · Address differs
A person decides · approved
Analyst approves the file
Then
Customer onboarded
Built on · Document AI · Gemini Enterprise · BigQuery
Read every workflow as text
KYC and onboarding files
KYC analysts and onboarding teams
The agent reads identity and entity documents, checks them against your policy, and assembles the file with every gap and mismatch listed, so the analyst starts from a finished file.
A person decides: An analyst approves every file. Nothing onboards a customer on its own.
We measure: Files closed per analyst per day, time to onboard, and files sent back for missing documents.
Built on: Document AI, Gemini Enterprise, BigQuery
Alert investigation summaries
AML investigators
For each alert, the agent pulls the transactions, counterparties and earlier alerts into one case summary and drafts the narrative, citing the record behind every sentence.
A person decides: The investigator decides whether to file. The agent never files a report.
We measure: Investigator time per alert, and the backlog of open alerts.
Built on: BigQuery, Gemini Enterprise, Agent Platform
Regulatory reporting with lineage
Finance, regulatory reporting and internal audit
Reporting pipelines record lineage from source table to reported figure, so the question of how a number was calculated takes one query to answer.
A person decides: Your controller signs off every filing.
We measure: Days to close and file, and adjustments after a figure is reported.
Built on: BigQuery, Knowledge Catalog, Dataflow
Claims intake
Claims handlers and adjusters
First notice of loss arrives with forms, photos and letters. The agent sorts them, matches the policy and its coverage clauses, and asks for what is missing before the file reaches an adjuster.
A person decides: The adjuster decides coverage and payment.
We measure: Time from first notice to a complete file, and adjuster time per claim.
Built on: Document AI, Gemini Enterprise, Cloud Storage
Underwriting submissions
Underwriters and underwriting assistants
Broker submissions, loss runs and schedules are read into structured data and checked against your appetite guidelines, so underwriters spend their time on the risks worth pricing.
A person decides: The underwriter prices and binds every risk.
We measure: Time to quote, submissions quoted, and underwriter time per submission.
Built on: Document AI, BigQuery, Gemini Enterprise
Fraud scoring in the payment path
Fraud operations teams
Scoring runs inside the transaction flow, payments your rules hold land in one queue with their reasons, and nightly batch stays for reporting.
A person decides: Your fraud team writes the rules that hold a payment, and an analyst releases or blocks every one.
We measure: Fraud losses, false positives per real case, and genuine payments held.
Built on: Pub/Sub, Bigtable, Agent Platform, BigQuery or Databricks
Payments and reporting, moved in stages
CIOs, CTOs and platform teams
Payments, reporting and digital banking workloads move one stage at a time. Old and new run side by side until the new one is proven, and every stage has a rehearsed way back.
A person decides: Your change board approves every stage and every cutover.
We measure: Downtime per stage, and the cost to run against the old platform.
Built on: Google Kubernetes Engine, AlloyDB, Cloud Interconnect
The examiner's questions
Every answer comes with its proof.
Pick an examiner's question to light the systems its evidence comes from.
Question and answer
Where the evidence comes from
One query returns the ticket, the reviewer and the deploy log.
Change ticket
Linked to commit
Code review
Named approver
Pipeline
Cloud Build
Deploy log
Cloud Logging
A policy pins storage to approved regions. The inventory lists the rest.
Org policy
Allowed regions
Projects
Per environment
Storage
Pinned region
Inventory
Cloud Asset
Lineage shows the tables and pipeline steps behind the figure.
Source tables
Core, cards
Pipelines
Dataflow
Warehouse
BigQuery
Lineage
Knowledge Catalog
Expiring grants and a data access log produce the list.
Access request
Privileged Access
IAM group
Expiring grant
Access log
Cloud Audit Logs
Review
Quarterly
A reference design. Your controls and regions decide the exact chain.
Proof from a neighboring field
The closest work we have shipped.
We have not published a financial services case study yet. The closest: document onboarding with a person approving every output.
Public Sector
Client onboarding cut from six months to weeks
A government and non-profit health and human services case management platform
Public Sector · Document AI · Google Cloud
80 to 90%
of form onboarding effort automated
Read the study
What is changing
More cases to work, and new guidance that leaves agents to you.
Each item is dated and sourced, ready to forward to your risk committee.
2.8M
suspicious activity reports filed by banks and other depository institutions in fiscal 2025
7,700
reports a day, each with an investigation behind it
2025
$15.9B
in fraud losses consumers reported to the FTC in 2025
Investment scams alone were $7.9 billion. Each report is a case someone works.
FTC testimony to the Joint Economic Committee, March 20262026
90%+
of bank data users say the data they need is often unavailable or slow to reach
It slows every report, model and investigation.
Deloitte 2026 banking and capital markets outlook17 Apr 2026
Out of scope
generative and agentic AI, in the agencies' new model risk guidance
Each model risk team now sets its own bar for agents.
OCC Bulletin 2026-13
Read every item in full
2025
Reported fraud losses reached $15.9 billion.
Consumers told the FTC they lost $15.9 billion to fraud in 2025, and investment scams accounted for $7.9 billion of it. Each report becomes a case that someone has to work.
2026
The data exists, and it takes too long to reach.
More than 90% of data users in banks say the data they need is often unavailable or takes too long to retrieve, which slows every report, every model and every investigation that depends on it.
17 Apr 2026
New model risk guidance leaves agents out of scope.
The OCC, the Federal Reserve and the FDIC replaced their 2011 model risk management guidance and withdrew the 2021 statement on model risk for BSA/AML systems. The revised guidance says generative and agentic AI are not within its scope, and the agencies plan a request for information on AI. Until that lands, each bank's model risk team sets its own bar for agents.
Example: AML alert investigation
Watch one workflow run end to end.
Corrandale Bank and every customer are made up, and the records are synthetic. The agent, its screens and its test results are real.
Read the narration
At 1:12 on a Tuesday afternoon, a customer of Corrandale Bank deposits $9,600 in cash.
Within 22 minutes, three more people deposit cash at three other branches, each deposit under $10,000.
On paper they're strangers, and the next day the bank's AML AI score raises an alert on one of them, Trent Halvey.
CloudMagic built this agent on Gemini Enterprise.
On November 9, that alert is one of 16 due for a decision by 4 the next afternoon.
It recommends a decision on each case with the reason from the records, and the investigator makes every call.
In 409, the agent has followed Trent through the bank's records to three other customers.
One iPhone signed in to all four accounts, tied to one verified phone number, even where two digits were swapped at onboarding.
At the counter, each of them told the teller the cash came from selling a pickup truck, a boat trailer, a coin collection, or equipment from a food truck that closed.
The agent tests every story against the records. Three of the sales have nothing on file, and the cash report Trent mentioned was never filed.
8 days earlier, that same iPhone added one payee to all four accounts in 13 minutes: Pemberline Freight, a company Trent owns.
Within the hour the cash was swept into Pemberline, and 41 minutes after the last deposit, $38,000 left for Hong Kong.
A first wire, rejected by the bank's gateway, carried a memo with an instruction aimed at an automated reviewer. Code removed it before the model read a word.
And the model only ever sees masked Social Security numbers.
Back at the desk, the investigator asks for the SAR narrative. The draft arrives in 27 seconds.
Before anyone reads it, code checks every amount, date, time and ID against the ledger. All 84 match.
Nothing is filed from here. The investigator approves it for the SAR committee, which decides whether to file.
If an examiner asks about this case months from now, the answer is on record: who approved it, when, and every number behind it.
CloudMagic builds agents like this on Gemini Enterprise, around a bank's own alerts, records and rules.
The engineering underneath
Try to make it decide.
Pick a request. Watch what the agent does with it, and what lands in the log your examiner will read.
As Adjuster assistant
As Relationship manager
As KYC analyst
As Support agent
As Model risk
Claims and onboarding agent
Signed in as Adjuster assistant
No tool here can approve, decline or pay. The file goes to an adjuster with the coverage clauses matched.
Audit log
- refused · approve_payment · adjuster assistant
A simulation of the controls we build into every financial services agent. It is not a live system.
- Runs inside your own Google Cloud project
- A person approves what the agent prepares
- Every action written to the audit log
- Scored against your past cases before launch
Read the requests and the engineering behind them as text
Adjuster assistant: Approve this claim for payment
Refused. No tool here can approve, decline or pay. The file goes to an adjuster with the coverage clauses matched.
Relationship manager: Onboard this customer now
Refused. Onboarding needs an analyst's approval. The file lists the gaps to close first.
KYC analyst: Which policy line says this is missing?
Cited. It cites the paragraph of your KYC policy it applied, from the version your policy owner signed off.
Support agent: Show me the card numbers on this account
Filtered. Card data is outside this agent's scope, so the request stops at the data layer.
Model risk: Show the test results
Scored. Your past files with known outcomes become a test set. Every change runs it, and a lower score blocks the release.
Policies turned into checked rules
It prevents: An agent reading your KYC or underwriting guideline differently from one file to the next. You check it: Every rule cites the paragraph it came from, and your policy owner signs off each version.
Decisions kept with people
It prevents: An agent approving a customer, a claim or a payment because a prompt talked it into it. You check it: No tool can approve, decline or pay. Every request for one is refused and logged with who asked.
Tested like a model
It prevents: An agent that passes a demo and fails model validation. You check it: We replay past files with known outcomes and give your model risk team the test set, the scores and the change log.
Evidence from configuration
It prevents: Exam preparation that runs on screenshots and memory. You check it: Access, change and data location questions are answered from logs and policy, with the query attached.
How we start
We begin with one queue and a fixed fee.
Most banks and insurers start with one queue, and a test set model risk can read.
First
A call with an engineer
Bring one workflow and its systems.
Fixed fee
Discovery
A written plan, or a written no.
Day 0 to 30
Build and test
Starts once access is approved. Validation runs alongside.
Day 30
One workflow live
On Gemini Enterprise, at a fixed fee.
After
Run it, or hand it over
Your call. The next one reuses it.
We need from you
- A queue owner
- A few hours a week from analysts
- Read access in your project
- Past files to test against
- Model risk in the room
What can slow it down
- Model validation: runs alongside
- Security review: answered up front
- Data access: masked copies first
You keep
- The code, in your repo
- The test set and its scores
- Runbooks and the audit log
- Your Google Cloud project
Read each step in full
A call with an engineer
Tell us the workflow and the systems it touches. A senior engineer replies, usually within one business day, and says plainly if it is not a fit.
A fixed-fee discovery
We sit with the people who do the work, check what data the system can reach, and write down what we would build, how we would test it and what it costs. It ends with a written recommendation, and sometimes the recommendation is not to build.
One workflow live in thirty days
Once access is approved, we put one workflow live on Gemini Enterprise in thirty days, at a fixed fee. Your model risk team validates it alongside the build, so go-live waits only on their sign-off.
Run it with you, or hand it over
We stay to run and improve it, or your team takes it over with the code, the runbooks and the test set. Either way, the next workflow reuses everything underneath.
What can slow it down, and what we do about it
- Model validation queues. Your model risk team gets the test set and documentation early, so validation runs alongside the build.
- Vendor and security reviews. We answer your questionnaire before the build starts.
- Access to production data. We start on masked copies while access is approved.
Frequently asked
The questions we hear first.
Many regulated banks and insurers run on Google Cloud, and Google publishes its compliance reports and the controls they cover. Acceptance is between you and your regulator, so we build what they will ask about: where data lives, who can reach it, how changes are approved, and the evidence for each.
The OCC's April 2026 model risk guidance leaves generative and agentic AI out of its scope, so most model risk teams are setting their own bar. We treat an agent like a model: you get the scope, a test set built from your past files, the scores from every run, the limits on what it can do, and a change log. A person makes every decision about a customer, which keeps the agent's role narrow and easier to validate.
No. It prepares the file, checks it against your written policy and lists what is missing. Underwriters, adjusters and analysts decide, and the agent has no tool that could approve, decline or pay.
No. It recommends what to do with each alert and gives the reason from the records, and it drafts the SAR narrative with every amount, time and transaction checked by code against the ledger. An investigator decides every alert, and the SAR committee decides whether to file. What an investigator approves is staged with their approval on record, and nothing is filed from the agent.
In stages. Old and new paths run side by side until the new one is proven, cutover happens one system at a time, and we rehearse the rollback before each step.
Yes. Organization policies limit the regions where resources can be created, so a database or bucket in the wrong place is refused, and the asset inventory shows where everything sits.
It suits fraud models, risk analytics and large reporting jobs where you want SQL and machine learning on the same data. We often pair it with BigQuery, depending on the workload and what your team already runs.
Our teams work from the US, London and Ahmedabad. Access to your data is granted per person, through your identity provider, inside your own Google Cloud project, and every access is logged. If your policy limits where people who see production customer data can sit, tell us on the first call and we will say plainly whether we can staff to it. We answer your third-party risk questionnaire before the build starts.
We build a test set from your past files with known outcomes, score every run, and give the scores to your model risk team. The same test set runs on every change after go-live, and a change that lowers the score does not ship.
You do. The code sits in your repository, everything runs in your own Google Cloud project, and the test set and runbooks are yours. Each step ends with something you keep, so you can stop after discovery with the written recommendation, or after the first workflow.
Yes. It runs on Gemini Enterprise in our own Google Cloud project, against BigQuery tables loaded with synthetic accounts and transactions for a made-up bank, Corrandale Bank. The bank and its customers are invented so we can show a whole investigation from start to finish, and no real customer data was used. The agent, its screens and its test results are real.
Tell us which queue you would clear first.
A senior engineer replies, usually within one business day.