Sankar Kalyanakumar

A queue holds hundreds of failed messages. Are they one problem or twelve?

Failed messages pile up in a holding queue and they all look alike. This groups them by cause (in my test run, 24 messages turned out to be 3 problems), then lets a person send one group back: practice run first, slow and stoppable, with a log of who did what. The AI explanation is optional and only sees the error text, never customer data.

The bank says a $4,217.50 payment arrived on Aug 29. Your books say Sep 1. Mistake, or just timing?

FinFlow compares two lists of payments and tries to explain every mismatch. It tries simple checks first: same amount, dates within 3 days, a reference typed slightly differently, an amount off by under 1%. Only what's left goes to an AI model that runs on my own computer. It also remembers past odd patterns. Runs on generated test transactions, not real bank data.

An AI suggests a trade. Who checks it before any money moves?

A checkpoint between a trading idea and the broker. It applies five rules, for example “never put more than 10% in one stock” and “a trade made by AI needs a human’s OK and a written reason”. Every check is saved so you can answer “why did this go through?” months later. It can also read new SEC filings and suggest rules for a person to approve.

Everyone has a trading strategy that “would have worked.” This tries to prove it wouldn’t.

A tester for trading strategies that blocks the usual ways to cheat by accident: it never uses tomorrow’s prices to make today’s decision, it charges trading costs on every trade, and it tests on time periods the strategy hasn’t seen. Comes with two simple strategies, and can send the same trades to a practice (paper) broker account to compare.

What happens inside a stock exchange between “buy” and “filled”?

A program that rebuilds an exchange’s list of buy and sell orders from NASDAQ’s real data format, and flags four kinds of cheating, such as placing a huge fake order and cancelling it half a second later. My first speed test said 45 nanoseconds per order; the honest measurement was 673. Fixing that taught me more than the code did.

A branch manager orders next week’s cash from gut feeling, plus 20% “just in case.”

Predicts how much cash each bank branch will need over the next 14 days from its past withdrawals (paydays, Fridays and so on), and recommends an order amount instead of a flat buffer. It also flags unusual days. Built and tested on generated data for 6 branches, so its accuracy numbers describe the model on that data, not a real bank.

2am. A service is down. The fix is somewhere in a 40-page runbook.

Ask a question in plain English and it finds the matching part of your own runbooks, answers using only that text, and names the file it came from. A separate AWS workflow can roll back a bad deployment, but only after a person approves it through an emailed link. A demo with 3 sample runbooks; it uses a local AI model by default, with AWS Bedrock as an option.

A truck breaks down. Its service was six weeks overdue. The spreadsheet was the last to know.

Keeps track of vehicles, drivers and maintenance jobs. Every hour it looks for overdue jobs and raises one alert per vehicle, not a fresh duplicate every hour. Has a web dashboard and a documented API.