Inspiration
Savings circles let people contribute regularly and take turns receiving a pooled amount. Traditions like tandas rely on relationships and community trust, but if someone stops contributing after receiving their turn, other members lose money.
As a statistics major, I wanted to explore how an organizer could understand payment risk before discussing payout order. Tanda was built to make estimates and uncertainty understandable while still keeping decisions in the organizer’s control.
What it does
Tanda connects three parts of a savings-circle workflow:
- Understanding risk: estimate each member’s payment reliability, show uncertainty, and compare all 720 payout orders for a six-member circle.
- Reviewing a proposal: see who receives the next pot and what the round involves before approving it.
- Verifying execution: collect authorized contributions and confirm the winner’s payout through PayPal’s sandbox.
A Gemini coordinator explains the computed results and can propose a round through four simple tools. Payment execution is outside the tool list. A person has to approve each round.
The hosted Render demo simulates payments. The separate local runner performs the PayPal sandbox API calls using test balances. All member payment histories are simulated and no real money moves.
How I built it
Python calculates Bayesian reliability estimates and 90% credible intervals using a grid of 199 candidate probabilities. The loss model combines possible missed payments and evaluates payout orders under explicitly stated assumptions.
PayPal’s Orders API saves authorized wallets and collects later contributions. The Payouts API sends the pot to the selected recipient. A local journal records payment operations and transaction IDs so an interrupted round can check existing transactions before continuing.
Google Gemini uses function calling to read the circle’s status, inspect a member’s estimate, score payout orders, or propose a round. Streamlit provides the interface, and Render hosts the public dry-run demonstration.
Working payment evidence
For the November 5 sandbox rehearsal, the local runner collected six completed contributions of $5 each.
The payout initially returned PENDING, so Tanda stopped without marking the winner paid. Resuming the same circle checked the same payout batch without recreating contributions. It then confirmed SUCCESS, and Ana’s matching recipient receipt showed $30 received with the note “Tanda round 1.”
The repository shows the contributions, terminal recovery output, and matching recipient receipt. The prefunded sandbox balance covered transaction fees.
Challenges and what I learned
Wallet authorization, asynchronous payment states, and recovery was a bit tricky. I learned how a timeout does not necessarily mean a payment failed, and a pending payout must not be treated as completed.
The statistics part also needed a lot of testing. An early probability grid could not represent very reliable members adequately. Simulation exposed this limitation and helped make a finer approximation.
Comparing against a simple baseline was another important lesson. With equal-length histories, the Bayesian ranking performed similarly to ranking by observed payment rate. Mixed histories showed an improvement. The uncertainty estimates remain useful even when the recommended ordering is similar.
Overall, the main takeaways were how to connect statistical calculations, payment APIs, and AI tool use while keeping responsibilities clear.
Validation
The simulation study checked interval coverage and compared payout strategies using known simulated probabilities. Average interval coverage was around 90%, but individual settings varied.
The project also includes 29 automated tests covering payment state, recovery, wallet setup, approval boundaries, and the simulated application flow. These tests use fake API responses and the November 5 receipts provide separate sandbox integration evidence.
So, these findings did demonstrate implementation and model behavior, but do not establish improved outcomes for real communities.
What next
I want to learn from circle organizers on whether the estimates are understandable, if the assumptions reflect their experience, and how risk information should sit alongside urgency, fairness, and existing agreements.
This prototype currently assumes independent member payment probabilities and focuses on missed payments after payout. It has not been tested with real organizers or actual payment histories. But the first payment round has been verified against PayPal’s sandbox.
Tanda’s purpose is connecting risk estimates, AI explanations, human approval, and verifiable payment execution around a savings practice communities already value.
Development assistance
Claude helped with initial coding, debugging, and explanations. OpenAI Codex assisted with review, payment-state fixes, tests, and submission preparation. Google Gemini is the AI service I used for integration into the running application.
