LockBox — AI-enabled FinOps tool

2024

Designed an internal FinOps tool where AI reads incoming financial documents and suggests matches, while operators verify and make the final call.

LockBox review screen: a scanned financial document on the left, AI-extracted data and a suggested employee match on the right

Context

The company administers Health Savings Accounts for employers and employees across the U.S. Every transaction has to be coded properly, or members end up with tax problems.

Heavily regulated
HSA funds can’t just be moved around freely.
A small FinOps team
5–15 people handled all of it.
Four document types
Transfers, checks and repayment requests, each with its own rules.

Problem

Every incoming document was processed by hand. Engineering had started using AI to extract data from scans, but there was no interface around it.

1. Open the scan
Transfer forms, checks, repayment requests.
2. Find the member
Searched by hand in the system.
3. Apply the transaction
Each one reviewed and applied manually.
AI with no interface
Extraction worked, but operators couldn’t use it.

My role

I was the sole designer, from business requirements through final UI, testing and edge-case coverage.

Regulatory logic
Worked through it with product management before opening Figma.
Shared layout
One layout for all four workflows.
Testing
Complete flows with the FinOps specialists who use it daily.
Components
Built reusable with engineering, across workflows.

Process

Regulatory logic before layout

Four document types, each with distinct rules. I mapped decision trees with product management first: what happens when a check matches no claim, or when a repayment can be partially denied. Those answers shaped the interface more than any layout decision.

One layout, four configurations

The team processes every document type in the same shift. After designing inbound and outbound transfers, I saw I was making the same decisions twice, so I formalized one layout: document on the left, extracted data on the right, suggestions below, actions at the bottom.

Testing with the people who’d use it

Walking complete flows with FinOps specialists changed real things: a check that matches no claim, an incomplete form, a repayment split across three claims.

4
document workflows
1
shared layout
5
decision actions: approve, partially approve, decline, pend, cancel

LockBox inbound transfer of assets: a scanned check on the left; on the right the document type, vendor, AI-extracted employee details and a suggested employee with an All Data Matched badge — Inbound Transfer of Assets. The check is scanned on the left. On the right: AI-extracted fields and a suggested employee match with an “All Data Matched” confirmation.

LockBox outbound transfer: a dense scanned transfer-of-assets form on the left, the same extracted fields, close-account option and suggested match on the right — Outbound Transfer. A denser document but the same layout. The operator doesn’t need to relearn anything between document types.

Solution

The AI always shows its work

Challenge: I first considered hiding the detail when the AI was confident. Operators told me they wanted to see the data regardless: on regulated accounts they need to know why it matched.
Solution: Every extracted field sits next to the scanned document. A green “All Data Matched” badge or a yellow mismatch warning sums it up, and manual search is always there as a fallback.

LockBox claim repayment: a scanned check beside two suggested claims, one marked Claim Number and Employee Name Matched and one warning Employee Name Doesn’t Match, each with an allocation field, then approve, partially approve, decline, pend and cancel options — Claim repayments are the hardest case: two possible claims with different match confidence, and the operator allocates the funds.

The unhappy path, structured

Challenge: Declines, partial approvals and split repayments each trigger different downstream actions, and all of it has to stand up to compliance review.
Solution: Declining needs a specific reason and a note; repayments can be split or partially approved; every action is logged with the operator's name and time.

Decline flow for an inbound transfer: a list of decline reasons with one selected, a note field with a character count, a for-benefit-of field and a red Decline button — Declining requires a specific reason. The note field and structured reasons keep the audit trail useful for compliance review.

Returned check record: the scanned form on the left; on the right the check details, the selected check’s history, and a logged reissue action with the operator’s name and timestamp — Returned checks show the full history of the original check. After processing, the operator’s action is logged with name and timestamp.

Outcome

From manual data entry to verification and exception handling.

The repetitive identification work was automated; the team's role shifted to the judgment calls that need a human.

Four workflows on one foundation.

A new document type plugs into the same structure: document, data, suggestion, decision.

What I learned

Start with what goes wrong
The edge cases define the system. Next time I’d map the failure states before sketching a single screen.
Let the users set the trust level
Being consistently transparent lets people build their own judgment about when to rely on AI.