Vigil

Inspiration

Fintech companies move money quickly, but their risk teams still need to stop suspicious activity before it clears. A single payment may look normal on its own. A pattern across sender behavior, payment rail, transaction size, risk score, and recent activity can tell a very different story.

Vigil was created for the purpose of entering this hackathon.

The inspiration was a common fintech workflow: transactions arrive continuously, rules flag risky activity, analysts investigate alerts, and teams adjust rules as new patterns appear. Vigil brings that loop into one live workspace.

What it does

Vigil is a risk operations command center for fintech transaction monitoring.

It ingests transactions, scores them, evaluates active risk rules, and creates alerts when something needs review. An analyst can open an alert and see the transaction amount, sender, receiver, payment rail, risk score, the rule that fired, recent related activity, and an audit timeline.

Vigil also includes a no-code rule builder. A team can create a rule, such as flagging wire transfers over $25,000, and backtest it before activation. The backtest shows how many historical transactions would have matched, the total dollar volume affected, estimated daily alert load, top matches, and query execution time.

How we built it

Vigil is built with Next.js, Vercel, Aurora DSQL, Drizzle, and server actions.

Aurora DSQL stores the operational data behind the workflow: transactions, alerts, rules, audit logs, and idempotency records. The app uses UUID primary keys, tenant-scoped idempotency keys to prevent duplicate ingestion, and version numbers on alerts so concurrent updates do not overwrite each other silently.

When a transaction enters the system, Vigil writes it once, evaluates active rules, creates matching alerts, and updates the analyst workflow. The rule backtest runs against historical transactions and returns both risk results and database performance evidence, including execution time.

Challenges we ran into

Transaction ingestion had to be repeat-safe. Alert creation had to happen immediately after rule evaluation. Alert updates needed versioning so investigation state stayed consistent. The rule builder needed more than a form; it needed a backtest that showed whether a rule would create useful coverage or just flood the queue.

Aurora DSQL also pushed us to design deliberately around distributed transactional data. We kept relationships explicit, used UUIDs throughout, added idempotency at the application layer, and exposed query timing in the UI so database behavior was visible during the demo.

Accomplishments that we're proud of

Vigil shows a complete fintech risk loop in under a minute.

A transaction enters. Rules evaluate it. Alerts are created. An analyst opens a case. The system explains why it was flagged. The team creates a new rule. The rule is backtested against history. Then it is activated.

The backtest is the most pride-worthy feature. It turns a risk rule from a guess into a measurable decision, with match counts, dollar exposure, alert-load estimate, historical examples, and execution time.

What we learned

A fintech risk system is only useful if it connects detection, investigation, and rule improvement.

A transaction table alone is not enough. An alert queue alone is not enough. The useful workflow is the chain between them: incoming transaction, triggered rule, alert detail, entity activity, audit history, rule backtest, and safe activation.

What's next for Vigil

Next, Vigil could support real payment webhooks, multi-tenant fintech workspaces, analyst assignment queues, case comments, richer rule conditions, exported audit reports, and automated case summaries.

The larger goal is to build a B2B monetizable business to help fintech risk teams move faster without losing control: detect suspicious activity, explain why it matters, test rule changes against history, and deploy those changes safely.

Built With

• amazon-web-services
• drizzle
• next-js
• vercel