Assay
Try the live demo

About

One founder, working software, no customers yet.

I'm Parikshit Ambhore. I build software for regulated financial operations, and Assay is my attempt to take the clerical work out of AML alert review without taking the analyst out of the decision.

Parikshit Ambhore

Parikshit Ambhore

Founder, Assay

Based in
Houston, Texas
Before
5+ years in software engineering, payments and transfer agency
Now
MBA candidate, Rice University, Jones Graduate School of Business, Class of 2027

Why I am building this

I spent more than five years as a software engineer on payments and transfer agency platforms. As a lead engineer at FIS, I delivered an institutional transfer agency platform for a global asset manager. Before that I built supply chain and payments systems at Cybermatic Systems. Transfer agency and payments are regulated, record-heavy work: every investor record and every money movement has to stand up to an audit.

On those platforms I saw where the hours went. The slow part was rarely the software. It was the queue of exceptions waiting for a person to pull records from several screens, check them against a rule, and write down why the item was fine. Most of them were fine. All of them took the same time.

More recently I have built LLM and agentic workflow automation, and learned where it breaks. It is quick at gathering and summarizing, and it will state things that are not in the records unless something checks it. Both lessons are in Assay: the agent does the gathering and the first draft, and deterministic code checks every citation and dollar figure it writes.

I am now an MBA candidate at Rice University in Houston, Class of 2027, and building Assay alongside the program.

Where it stands

  • The product is working software: the triage engine, the workbench, the REST API and CSV import, billing, and a demo that runs in your browser on 44 synthetic alerts.
  • It has never processed real customer data. There are no customers and no revenue.
  • Performance numbers on this site are modeled and labeled as modeled until a pilot measures them.
  • I am looking for three design partners to run a shadow-mode pilot on their own historical alerts.
  • “Assay” is a working name; trademark and domain clearance are pending.

What I believe about the problem

Four convictions the product is built on.

  1. The work to remove is assembly, not judgment.

    Up to 85% of financial crime compliance work is administrative or nonanalytical.1 Pulling the same records for every alert and writing down why it is fine is exactly the work software should take. Deciding what is suspicious is not.

  2. An agent that cannot show its sources does not belong in the queue.

    Language models are fluent and confident, and they will cite things that are not there unless the system checks. In Assay every claim cites a record, and code verifies the citation and the dollar figure before an analyst sees it.

  3. Autonomy should be earned per alert type, on the bank's own data.

    Payroll alerts and sanctions name matches do not deserve the same trust. Shadow mode and QA sampling measure agreement type by type, and the autonomy ladder moves only when a named owner or admin moves it, with those numbers in front of them.

  4. Some decisions stay human by design.

    Filing a SAR, clearing a watchlist match, contacting a customer and changing the agent's own policy are not settings. There is no code path for them, and there should not be.

How to reach me

Email is fastest.

If you run an alert queue, own a BSA program or validate models at a bank, credit union, sponsor bank or MSB, I would like to hear how your team works today, whether or not you want a pilot.

Design partner program

No customers yet. Three design partner slots.

Assay is working software running on synthetic data. Nobody has put production alerts through it. The proof available today is the product itself, counted from its code, and a pilot designed so you can measure it on your own dispositions before trusting it with one.

What exists today

synthetic alerts in the public demo, each one built to test a specific rule or edge case
44
alert typologies with their own autonomy setting, from structuring to payroll
7
deterministic policy rules that run before and after the model on every alert
6
actions the agent has no code path to take, starting with the SAR decision
4
  • Slot 1Open
  • Slot 2Open
  • Slot 3Open

Three is a goal for the first pilots, not a waitlist.

Who it is for

US banks and credit unions, fintech sponsor banks, and money services businesses with 2 to 25 L1 analysts working transaction-monitoring alerts.

What you get

  • A shadow-mode pilot on your historical alerts. The agent runs, your analysts never see it, and you get agreement by alert type against your own dispositions.
  • It runs in your own Azure tenant with your own model endpoint, so alert data stays inside your boundary.
  • Free for the length of the pilot.
  • A direct line to me, the founder, for the whole pilot.
  • Real influence on the roadmap: integrations, typologies and the model risk pack get built in the order partners need them.

What I ask

  1. 30 days of historical alerts with their final dispositions.
  2. Two 30-minute feedback sessions with whoever owns the queue.
  3. Permission to publish the results, anonymized.
Become a design partner