From Tally to CoTreasury: Building Trust Into Collective Finance with AI and Payment Infrastructure

I started building fintech applications because of a problem I had observed in the way people manage money together: trust.

In many African communities, particularly in Nigeria, collective savings and contributions are part of everyday life.

Market women belong to savings associations. Families pool resources for important responsibilities. Friends contribute towards shared goals. Cooperatives organise regular contributions, loans and repayments.

These arrangements help people achieve things they might not be able to accomplish individually.

However, there is often an imbalance in how the money is managed.

One person, usually a president or treasurer, may be responsible for holding the funds, recording transactions and deciding when money should be spent. Other members contribute but may have limited visibility into the group's financial activities.

I wanted to explore a different model.

What if everyone could see the same financial records? What if withdrawals required agreed approvals? What if groups could establish spending rules before collecting money?

My interest in this problem was also influenced by my background in Web3 and cryptocurrency.

One of the things I appreciated about blockchain technology was its public ledger: the ability to inspect transactions and verify financial activity rather than depending entirely on someone's explanation.

I became interested in bringing some of these principles into traditional financial applications.

That interest eventually led me to build three successive applications: Tally, TrustLedger and CoTreasury.

This is the story of how the idea evolved, the technical decisions I made and what I learned along the way.

1. Tally: Building the first version

My first opportunity to explore this problem came during the AI Build Fest Hackathon in 2026.

I called the application Tally.

The initial scope was focused on group contributions and shared financial goals.

Imagine a group of friends planning a trip. Everyone agrees to contribute a certain amount, but keeping track of commitments, actual payments and the remaining amount can quickly become complicated.

Payment screenshots may be scattered across WhatsApp conversations, while the organiser maintains a separate spreadsheet.

Tally was designed to bring these activities into one shared application.

What I built

The application allowed users to:

• Create a shared financial goal.
• Set a contribution target.
• Invite participants using a shareable link.
• Track individual commitments.
• Record payments.
• Maintain a view of fundraising progress.
• Manage supporting payment evidence.

The idea was to give every participant a clearer understanding of the group's financial position.

Technical approach

I used TypeScript and built the financial functionality around deterministic application logic.

One important component was the financial calculation layer.

For example, the application needed to calculate:

• Total confirmed contributions.
• Outstanding commitments.
• Remaining funding requirements.
• Fundraising progress.
• Budget shortfalls.

These calculations were handled by application functions rather than delegated to an AI model.

This distinction became a recurring principle in my later projects: AI can help interpret information, but important financial calculations should remain predictable and verifiable.

I also implemented payment-recording and receipt-review functionality.

Tally gave me an opportunity to experiment with translating a financial problem into a working web application.

The first recognition

Tally won the budgeting category at AI Build Fest 2026, received a $350 prize and was selected among the top 10 finalists.

It was my first major hackathon recognition and gave me the confidence to continue developing the idea.

But I realised that contribution tracking was only the beginning.

I wanted to address what happened after money entered the group.

Who could spend it? Who could approve withdrawals? How could members understand the complete history of their contributions and expenses?

That became the foundation for TrustLedger.

2. TrustLedger: Designing a shared financial ledger

For the GOMYCODE Come Build with AI Hackathon, I expanded the original concept.

Instead of focusing mainly on groups collecting money for a particular goal, I designed TrustLedger for savings groups and cooperatives that regularly contribute, borrow, repay and manage funds.

TrustLedger was built around one central idea:

A group's financial position should be connected to its transaction history.

The problem

Traditional informal financial management often involves multiple sources of information:

• Bank transfer receipts.
• WhatsApp messages.
• Notebooks.
• Spreadsheets.
• Manually maintained payment records.

When these records are scattered, it becomes difficult to establish an accurate picture of the group's finances.

TrustLedger was designed to turn these activities into a shared, structured financial history.

How the application works

Every contribution, expense, repayment and payout is recorded as a financial event.

Members can submit payment evidence, while administrators review and confirm the relevant records.

The application uses these records to maintain the group's financial position.

Rather than relying on an independently entered balance, the system calculates the position from recorded financial activity.

For example:

A group starts with contributions of ₦500,000. It records an expense of ₦100,000 and subsequently receives a repayment of ₦20,000.

The resulting position is derived from the financial events:

₦500,000 - ₦100,000 + ₦20,000 = ₦420,000.

This is a simplified illustration of the ledger principle.

The important part is that the balance has an underlying history that members can inspect.

Architecture and technology stack

TrustLedger introduced a different backend architecture from my first application.

The stack included:

| Layer | Technology | Purpose |
|---|---|---|
| Backend | Python | Application logic |
| API | FastAPI | Application endpoints |
| Database | SQLite | Persistent data storage |
| Validation | Pydantic | Validating structured data |
| Frontend | HTML, CSS, JavaScript | User interface |
| AI | NVIDIA Llama 3.2 11B Vision | Receipt information extraction |
| Matching | RapidFuzz | Name matching |
| Image processing | Pillow | Receipt image handling |
| Testing | pytest | Automated tests |
| Deployment | Railway | Application hosting |

AI-assisted receipt extraction

One of the interesting features was the integration of NVIDIA's Llama 3.2 11B Vision model through the NVIDIA Build API.

I used it to help extract information from receipt images.

The process involved taking an image containing financial information and using the vision model to identify relevant details.

Those details could then be passed through application-level validation and matching logic.

I used RapidFuzz to help match names in extracted information, while Python handled the application's financial rules.

The distinction was important:

The AI could extract what appeared to be a transaction amount, but the application still needed to validate the information before treating it as a reliable financial record.

A receipt is evidence of a payment claim; it is not automatically proof that the money has arrived.

Financial precision and accountability

I also used integer-based monetary representation in kobo rather than floating-point values.

This was important because floating-point arithmetic can introduce precision issues when working with decimal amounts.

TrustLedger also introduced controlled withdrawal workflows.

A withdrawal could be requested by an authorised person, but another designated person had to approve it according to the group's rules.

The application also maintained financial histories for members and groups.

I documented 37 automated tests using pytest, covering areas such as permissions, financial records, payment verification and approval restrictions.

Recognition

TrustLedger received the Kredete Financial Inclusion Award at the GOMYCODE Come Build with AI Hackathon.

This recognition reinforced my interest in building technology around financial inclusion and accountability.

But I still wanted to explore something beyond financial records.

I wanted to connect the application to the infrastructure that processes payments.

That led to CoTreasury.

3. CoTreasury: Integrating payment infrastructure

CoTreasury was my project for the PayPal AI Hackathon.

It represents the most developed iteration of my original idea.

The concept is a shared treasury where groups can contribute funds, define spending rules, approve payments collectively and maintain a verifiable financial history.

Unlike the earlier applications, CoTreasury allowed me to explore a more complete payment lifecycle using the PayPal Developer Platform.

This was particularly exciting because it was my first opportunity to integrate payment infrastructure into one of my applications at this level.

Product design

Consider a family and a group of friends pooling money to sponsor someone's education.

They contribute towards tuition, accommodation, textbooks and other educational expenses.

Instead of transferring all the money to one person and relying on periodic updates, the group could maintain a shared treasury.

Each expense would have a description and an approval process.

Members could follow the financial activity from the first year of school through graduation.

This is different from a conventional crowdfunding model where contributions are collected and handed over to the beneficiary without necessarily maintaining ongoing collective oversight.

Another example is a married couple managing shared financial goals.

The couple could establish monthly targets, describe spending requests and require both members to approve payments before they are initiated.

The idea is to make shared financial management more transparent and deliberate.

4. CoTreasury architecture

For this version, I used a different stack.

The architecture can be understood through five major components.

A. Application layer

Next.js provides the main application structure.

It handles the user interface, application routes and server-side operations.

TypeScript provides type checking across the application, helping catch certain implementation errors before runtime.

Prisma acts as the database access layer, allowing application code to interact with SQLite through a structured data model.

B. Payment integration layer

This was one of the most important additions.

I integrated several PayPal services.

PayPal Orders v2 and JavaScript SDK v6

These support the contribution workflow.

The application creates an order, presents the payment experience and captures the payment after approval.

PayPal Payouts

This supports outgoing payments following the required group approval process.

PayPal Webhooks

Webhooks allow PayPal to notify the application about payment events.

I implemented signature verification so that the application could validate incoming webhook notifications before using them to update financial records.

This is important because a browser redirect or a message from the frontend should not independently establish that a payment succeeded.

PayPal Transaction Search

I used Transaction Search to compare the connected PayPal account's activity with the transactions recorded in CoTreasury.

This helped identify activity that did not originate from the application's own payment workflows.

C. Governance and approval layer

The application separates the creation of a spending request from its approval and execution.

A member submits a request. The application evaluates the applicable rules, including the amount and other conditions.

The required number of approvals is determined by the server using the group's rules.

Once sufficient approvals have been received, the payout can proceed through PayPal.

I also explored fixed approvers and randomly selected hidden approval panels for certain spending scenarios.

The goal was to make the approval process less dependent on a single person's discretion.

D. AI Treasurer

I integrated Claude through the Anthropic SDK with tool use.

The AI Treasurer allows members to interact with financial information using ordinary language.

For example:

"Can we afford a $1,400 deposit?"

The AI can retrieve the treasury's financial state and use the affordability-checking functionality.

It can also help prepare contributions and draft spending requests.

I implemented four tools for the AI Treasurer:

1. Read treasury state.
2. Check affordability.
3. Prepare a contribution.
4. Draft a spending request.

The AI does not have permission to approve or execute payments.

The server recalculates the relevant financial amounts and approval requirements. Human members retain the authority to approve spending.

This was a deliberate architectural boundary.

I wanted AI to assist with understanding and preparing financial actions without becoming the authority that controls collective money.

E. Tamper-evident activity log

Another component is the activity log.

I implemented a hash-chain approach using SHA-256.

Each activity entry stores its own hash and the hash of the preceding entry.

Conceptually:

Entry 1 → Entry 2 → Entry 3 → Entry 4

Each entry is linked to the previous one.

If an earlier entry is changed, the integrity of the subsequent chain is affected.

Members can use the integrity-checking functionality to examine whether the history remains consistent.

This does not make the system tamper-proof. Someone with sufficient database access could theoretically rewrite the entire chain.

A future improvement would be publishing the latest hash outside the application to provide an independent reference.

5. Engineering challenges and decisions

Building CoTreasury exposed me to several problems that required more than simply implementing API calls.

Understanding PayPal account ownership

One important limitation came from the Sandbox account arrangement.

A PayPal business account belongs to the person or entity that registered it. The application cannot prevent that account holder from independently moving money through PayPal.

I therefore designed a reconciliation approach using PayPal Transaction Search to identify transactions that were not initiated through CoTreasury.

The application could then expose those movements to the group.

This was a constraint of the available Sandbox resources and account arrangement during the hackathon. A future implementation could explore connecting each group's own account through the appropriate PayPal partner onboarding infrastructure.

Payment reconciliation

A single payment funded from a bank account can generate multiple related records in PayPal.

If the application treats every record as an independent payment, it can generate false external-activity alerts.

I had to account for related transaction records so that the reconciliation process would not incorrectly flag legitimate activity.

Transaction Search also required enabling the capability for the application and respecting its supported date ranges.

Voting logic

My initial voting implementation allowed one negative vote to terminate a request.

I changed this behaviour.

The revised approach allowed a request to pass as soon as it received the required approvals and fail only when it could no longer receive enough approvals.

This meant members could participate without one early negative vote automatically ending the process.

Refunds and member exits

I also had to consider what happens when a member wants to leave a group.

What happens if a refund is requested but the group does not approve it?

I designed the workflow so that a rejected refund request did not automatically remove the person from the group. If the member escalated the matter through PayPal, the relevant share could be held pending the outcome, with appropriate restrictions on their participation in spending decisions.

These situations helped me understand why financial applications need to account for exceptions and disagreements, not just successful payment scenarios.

Isolated demo environments

Because judges needed to explore the application independently, I implemented separate demo environments for different browser sessions.

This allowed judges to explore member roles without interfering with one another's demo data.

Real treasuries were designed to remain private, with members joining through invitation links.

Improving AI responses

Early versions of the AI Treasurer sometimes produced unnecessarily long responses and could make assumptions about approval counts.

I refined its instructions so that it would rely on its application tools for financial information, answer only what was asked and avoid inventing approval figures.

This reinforced another lesson: AI behaviour needs boundaries, not just access to tools.

6. What I learned from the three projects

Looking at the progression, I see a clear development in my technical thinking.

Each project built on the questions raised by the previous one.

Some of the most important lessons were:

1. AI is an assistant, not an authority.

AI can help interpret documents and make complex financial information easier to access. However, financial calculations, permissions and payment execution should remain controlled by deterministic application logic and authorised people.

2. Financial transparency requires an understandable history.

Showing a balance is not enough. Members need to understand the transactions, decisions and evidence behind it.

3. Payment integrations require careful verification.

A payment should not be considered successful simply because the frontend says it is. Confirmation, webhook verification and reconciliation are important parts of the process.

4. Technical limitations should influence product design.

The PayPal Sandbox account arrangement taught me to distinguish between what the application could control and what it could only monitor. Rather than hiding that limitation, I designed around it and documented the infrastructure needed for future improvements.

5. AI-assisted coding still requires engineering understanding.

I used Claude and ChatGPT extensively while developing these applications.

They helped me explore unfamiliar technologies, implement features and move through development faster.

But generating code is not the same as understanding a system.

I still needed to inspect implementations, test different scenarios, debug unexpected behaviour and understand the consequences of architectural decisions.

This journey has made me more interested in the engineering behind AI-assisted software development and the design of reliable financial applications.

7. What's next?

My long-term interest is to explore how collective financial activity can become a verifiable financial history.

Individuals can often present bank statements when applying for loans or grants. Informal savings groups and cooperatives may have years of financial activity without a structured record that external institutions can easily assess.

A system like CoTreasury could eventually help groups build financial histories that may support access to formal financial services, subject to appropriate verification, privacy protections and partnerships.

Some of the improvements I would like to explore include:

• Connecting each group's own PayPal business account through appropriate partner onboarding.
• Publishing activity-log hashes outside the application.
• Improving notifications for payments and approval requests.
• Strengthening security and access controls for real-world deployment.
• Exploring partnerships that could make group financial histories useful to lenders and grant-makers.

I am also interested in the intersection of artificial intelligence, payment infrastructure and distributed systems.

My original interest in Web3 was driven by transparency and verifiable records. I now want to continue exploring how those ideas can be incorporated into financial applications that people can actually use.

I don't believe every financial problem requires blockchain or an AI agent.

I believe the more important question is how we can use the right technology to solve the problem in front of us.

For me, this journey started with a simple question about trust.

Tally was my first attempt at answering it. TrustLedger expanded the idea. CoTreasury brought me closer to the payment infrastructure behind it.

And I am still building.

Project repositories and demonstrations

Recognition

• AI Build Fest 2026 — Budgeting category winner, $350 prize; top 10 finalist.
• GOMYCODE Come Build with AI 2026 — Kredete Financial Inclusion Award.

Note: CoTreasury's PayPal integrations were developed and demonstrated using the PayPal Developer Sandbox. Sandbox transactions are simulated and do not represent live customer-fund processing. The applications described here are successive iterations of an evolving personal fintech project.