Software Should Support the Bank, Not Become It

by Robert Baron, CAMS

The pitch I kept hearing

In the early days of cannabis banking, the pitch arrived in my inbox almost weekly. A software company wanted to "lighten the load" on my team. They would run the monitoring, handle the filings, and take the burden off my desk. The price was somewhere between 30 and 200 basis points of our total marijuana-related business deposits, paid to them, every year, for as long as the program ran.

I ran the cannabis banking program at a federally insured credit union from the ground up. We banked 216 state-licensed cannabis businesses, including some of the largest multi-state operators in the country. Non-interest income grew 982 percent. Our return on average assets ranked first among federally insured credit unions. I know what that program cost to build and what it took to defend in front of examiners.

So when a vendor asked for a slice of our deposits, I asked the obvious question: why? They were not our depositors. It was not their revenue. The compliance risk sat with our charter, our BSA officer, and our board. Some of these companies went further and tied their fee to the profitability of the program itself, as if they had underwritten it. It felt like someone reaching into the vault and calling what they found their own.

Software should support the bank, not become it

That experience settled a conviction I still hold. A software provider has one job: make the institution better at the work it is already accountable for. It does not get to become the institution.

The basis-point model gets the relationship backwards. It treats the bank's deposit base as the vendor's revenue stream and the bank's compliance staff as a cost the vendor is kind enough to absorb. But the examiner does not write up the vendor. The board does not fire the vendor. The consent order, if it comes, carries the bank's name. You cannot outsource accountability, so you should not price the relationship as if you had.

Good software helps bankers do better. It does not do their job for them, and it does not charge them as though it had. The moment a vendor's fee rises with your deposits rather than with the work it performs, you have stopped buying a tool and started paying a partner you never agreed to take on.

That is the line StandardC was built not to cross. It is also the first reason I understood, years before I joined the company, why StandardC was different from every other provider knocking on my door.

One program, one BSA function, one set of alerts

Here is the second reason, and it is the one most banks learn the hard way. A cannabis banking program does not need a separate system to monitor transactions or file SARs. The bank already has one.

Every financial institution that opens its doors to marijuana-related businesses already runs a BSA/AML program. It has a core. It has a transaction monitoring platform tuned to its risk appetite. It has a case management workflow, a SAR filing process, a quality control step, and a BSA officer whose name is on the attestation. Those systems were examined last year and will be examined again next year.

When a vendor bolts a second monitoring engine onto that program, the bank does not get twice the coverage. It gets twice the alerts. The same wire that trips a rule in the bank's platform trips a different rule in the vendor's platform. Two analysts open two cases on two screens. Two narratives get written. Two audit trails have to be reconciled before anything is filed, and the filing itself still has to go through the bank's own process because the vendor is not the filer of record.

The cost is not only labor. Duplicate alerting creates systemic problems that compound over time:

• Conflicting dispositions. One system clears an alert the other escalates, and the bank now owns the inconsistency.
• Fragmented records. The examiner asks for the full history on a customer and receives it in two formats from two sources with two timestamps.
• Model risk. A second scoring engine is a second model the bank must validate, document, and defend under the same guidance that governs the first.
• Staff fatigue. Analysts who review the same activity twice start treating alerts as noise, which is exactly how real activity slips through.

‍

The cannabis vertical is different in what it demands, not in how it should be governed. Marijuana Limited and Marijuana Priority SARs follow the same filing discipline as every other SAR. The difference is the depth of due diligence and the volume of data the bank must reconcile: seed-to-sale records, point-of-sale reports, tax filings, financial statements, invoices, and the transaction activity sitting in the bank's own core. That is a data analysis problem on top of the bank's existing program. It is not a reason to run a second program beside it.

What we built instead

StandardC AI was developed with that distinction at its center. It does not replace the bank's transaction monitoring platform, and it does not file anything. It takes the data from the systems the bank already trusts and analyzes it in a way no person could: every source a cannabis relationship generates, reconciled together, at scale, with the same rigor every time. It does this at a fraction of the cost and time it would take an army of analysts to decipher the same data.

A single review triangulates the customer's data, the bank's data, and public data in one run. Seed-to-sale records from the state tracking system, sales reports, tax filings, financial statements, invoices, and receipts are reconciled against the activity in the bank's core and the alerts from its monitoring platform. StandardC AI builds a 90-day review table, surfaces variances and red flags, and applies the bank's own risk rating matrix, policies, and escalation protocols. The output is a report the bank's analyst reads, challenges, and acts on, including a prepopulated narrative the bank can carry into its own SAR process if its own review warrants a filing.

The architecture is intentional in three ways:

• It is deterministic where it matters. Calculations run through computational logic models that produce the same answer from the same inputs every time. Generative models draft narrative; they do not decide what the numbers are.
• It is predictable in cost. A review costs what a review costs, regardless of how large the customer's deposit relationship grows. StandardC has never priced a product in basis points of a client's deposits and never will.
• It keeps the bank in control. Every agent is customized to the institution's staff roles, procedures, and underwriting matrices, version controlled, and logged with the bank. Every report is archived with an immutable audit trail. The bank's existing workflow stays the workflow of record.

‍

StandardC has filed two patents for its Privacy First AI approach, built so that institutions can bring advanced analysis to sensitive customer data without surrendering control of it. The point of all of this is not to be clever. It is to let a BSA analyst do in an afternoon what used to take a week of spreadsheets, and to do it the same way on the hundredth customer as on the first.

Why StandardC exists

Allowing our clients to be better is the reason the company exists. Not better because a vendor took the work away, but better because their own people, on their own systems, can see more, reconcile more, and decide faster than they could before.

The banking industry has spent two decades adding tools that each solved one problem and created another. The institutions that win in high-risk verticals will be the ones that resist the urge to pile on systems and instead make the program they already have more capable. That is a harder product to build. It requires understanding how a BSA department actually runs, where the data lives, who signs the attestation, and what an examiner will ask in the exit meeting. It is also the only product worth building.

I spent over 15 years in banking and financial services before I joined StandardC. I know what it feels like to be told your program is too much for you to handle and that someone else should run it for a share of what it earns. The answer then was no. The answer StandardC gives today is the same, and we built the technology to prove it.

You provide a role to support an institution, not to become one. You help bankers do better, not do their jobs for them. Everything we have built follows from that, and it is why I am convinced that what we have done at StandardC is monumental, and deliberate.