About The Usual

Inspiration

I kept thinking about how small merchants and informal business owners in Nigeria manage everyday financial obligations.

A merchant might have paid a supplier in installments, owe another customer a balance, or need to refund someone. Most of the time, these instructions are communicated casually.

"Pay Emeka the remaining 50k for those chairs."

The problem is that remembering who is owed what, checking previous payments, calculating outstanding balances, and making sure the right person gets paid can become messy.

I saw an opportunity to make financial interactions feel more natural. Instead of forcing merchants to learn complicated financial software, what if they could simply explain what they wanted in their own words?

But there was another problem. Giving an AI assistant access to financial actions introduces a different kind of risk. Understanding an instruction is not the same as having the authority to execute it.

That distinction became the foundation of The Usual.

What it does

The Usual is a natural-language financial assistant designed around the everyday needs of small merchants.

A user can type an instruction such as:

"Abeg pay Emeka the remaining 50k for chairs."

The application interprets the request, identifies the relevant person, checks the existing ledger, calculates the outstanding balance, and prepares a payment draft with the evidence behind it.

The user can inspect that evidence before deciding whether to confirm, change, or refuse the action.

The application also handles situations where it should not proceed:

• If multiple people match a name, it asks for clarification.
• If a person is not an approved payee, it refuses the payment.
• If there is no outstanding balance, it does not create another payment.
• If an action cannot proceed, the reason remains visible.

The interface is organized into five pages:

• Prepare: Turn natural-language instructions into proposed actions.
• Evidence: Inspect the records and reasoning behind a decision.
• Ledger: View payees, balances, and transaction history.
• Activity: Follow the events generated during processing.
• Pending: See blocked, refused, or unresolved actions.

All payments in the current implementation are simulated. No real money moves, and no bank account is connected.

How I built it

I built The Usual around a simple architectural principle: the language model should interpret instructions, but it should not control financial state.

I used NVIDIA Nemotron through Nebius Token Factory for natural-language interpretation.

The model receives the user's instruction and helps translate it into structured information that the application can process.

From there, deterministic application logic takes over.

The backend checks the identified payee, existing ledger records, outstanding balances, authorization rules, and action constraints before deciding what can happen.

I also designed the action flow around four important outcomes:

• STAGE: Prepare an action that can be reviewed.
• ASK: Request clarification when information is insufficient or ambiguous.
• REFUSE: Reject an action that violates a rule.
• WAIT: Hold an action when it cannot safely proceed yet.

A staged action does not automatically become a completed transaction. The user must explicitly confirm it.

I built the ledger using SQLite and kept the payment flow simulated so I could concentrate on the correctness of the decision pipeline rather than introducing real financial integrations.

The frontend exposes the evidence and state transitions instead of hiding them behind a conversational interface.

Challenges I ran into

One of the biggest challenges was deciding how much responsibility to give the language model.

It is easy to build an assistant that turns a sentence into a payment request. It is harder to build one that knows when it does not have enough information to proceed.

For example, "Pay Chidi the balance" becomes complicated when two different Chidis exist in the ledger.

A model might confidently select one. I did not want confidence to be mistaken for correctness.

I had to separate language interpretation from identity resolution, authorization, and financial calculations.

Another challenge was maintaining consistency between proposed actions and the actual ledger state.

A payment that has already been recorded must not become payable again simply because the user repeats the original instruction. This required careful handling of state changes, confirmation, and duplicate-action prevention.

I also had to account for interrupted requests and uncertain confirmation outcomes. A network failure should not leave the user guessing whether an action was recorded or encourage an unsafe second execution.

Finally, I had to make the evidence visible enough that someone using the application could understand why an action was proposed or refused.

Accomplishments that I'm proud of

I'm particularly proud of the separation between AI interpretation and financial authority.

The model can misunderstand a sentence, but that interpretation alone cannot change the ledger.

I'm also proud of building a workflow that handles more than successful requests. Ambiguous identities, unapproved payees, repeated instructions, and refused drafts are all important parts of the application.

Other accomplishments include:

• Building a natural-language interface around everyday merchant instructions.
• Implementing a deterministic decision pipeline.
• Making the evidence behind proposed actions inspectable.
• Separating preparation, confirmation, and recording.
• Maintaining an activity trail of important application events.
• Building a multi-page interface around the actual responsibilities of the system.
• Keeping the current implementation independent of real payment infrastructure.

I wanted to build something that demonstrates not just what an AI assistant can do, but also what it should not be allowed to do.

What I learned

The biggest lesson was that understanding a user's intention and safely acting on that intention are two different engineering problems.

A language model can interpret "pay the remaining balance," but it should not be trusted to invent the balance, choose between two people with similar names, or decide whether someone is authorized to receive money.

Those responsibilities need explicit rules and reliable application state.

I also learned that transparency is not just about showing users a final answer. It means making the underlying evidence and important state transitions available for inspection.

Most importantly, I learned that adding AI to a financial workflow does not mean every part of that workflow needs to become intelligent.

Sometimes the best use of AI is to handle the part humans find inconvenient, while leaving the critical decisions to systems that can be tested and verified.

What's next for The Usual

The current version uses simulated payments. My next goal is to move beyond the demonstration and build something that can support real merchant workflows.

I want to improve the handling of recurring obligations, supplier records, customer balances, refunds, and more complex financial instructions.

I also want to expand testing across different expressions, local language patterns, ambiguous requests, interrupted operations, and adversarial inputs.

Eventually, I want to explore carefully controlled payment integrations, stronger identity and authorization mechanisms, and better ways for merchants to maintain their financial records.

The long-term vision is straightforward:

A merchant should not need to understand complicated financial software to manage everyday obligations.

They should be able to say what needs to happen, see why the system proposes it, and remain in control of whether it happens.

The Usual is built around one rule: AI can prepare the action, but the user remains in control of the money.

Built With

• html
• javascript
• natural-language-processing
• nebius
• nvidia
• python
• sqlite