Meet the team:
Claire Campbell:
I am currently pursuing an MPhil in Financial Technology at the University of Cape Town, having previously completed a Bachelor of Business Science specialising in Computer Science. I am passionate about payments, financial innovation, and exploring the intersection of finance and technology to develop practical solutions to real-world challenges. I enjoy approaching complex problems with an analytical mindset and collaborating with diverse teams to bring ideas to life. Outside of my studies, I enjoy travelling, baking, and spending time outdoors.
Kerry-Lynn Whyte
I am currently pursuing an MPhil in Financial Technology at the University of Cape Town (UCT), having completed a Bachelor of Business Science specialising in Computer Science also at UCT. I am driven by solving complex problems, and I enjoy exploring how computer science, statistics and technology can be applied to the financial technology sector. My interests lie at the intersection of software engineering, data analytics, and financial technology, particularly in building practical solutions to real-world challenges. Outside of academics, I enjoy playing tennis and following both tennis and football - I’m always analysing player and team statistics. I’m also a lifelong Chelsea supporter.
Mridula Kumar
I'm Mridula, currently pursuing an MPhil in Financial Technology at the University of Cape Town, having completed a Bachelor of Business Science specializing in Information Systems, also at UCT. I enjoy exploring how data, statistics, and software engineering can be applied to the financial technology sector. I also love music: I play the piano, I'm currently learning the guitar, and the harp is next to learn on my list. I’m extremely passionate about using the access, opportunities, and gateways I have to transform the fintech space. To make it more inclusive and accessible so everyone is seen, heard, and accounted for in our rapidly digitally advancing world.
Our Hackathon Background:
This was Claire’s second hackathon and Mridula and Kerry’s first hackathon. We all really enjoy the collaborative aspect of hackathons – working together as a team and meeting other people who are also passionate about using technology to solve problems. The thing that stood out at this hackathon was the supportive nature of everyone involved – from the tutors to the Interledger staff, the judges as well as fellow hackathon students. Everyone was supportive and genuinely interested in hearing different teams’ ideas.
Preparation:
In terms of preparation, we listened thoroughly in the lectures as well as tutorials – taking note of possible problems and solutions along the way. Our backgrounds, which cover computer science, statistics, business and finance topics, as well as the coursework we have completed so far this year whilst pursuing our master's, helped immensely, and it was interesting to apply what we have learnt in a practical context. We learnt about the importance of understanding a problem thoroughly before coming up with a solution. We also learnt the importance of relying on each other when times get tough – had we not been able to divide up the work so efficiently, we would have been unable to complete the hackathon and develop a solution we were proud of and ready to present.
The Challenge:
We noticed that fires occur frequently in informal settlements, and community members cannot access formal insurance. As a result, community members are left particularly vulnerable when a fire wipes out their home - a fire can wipe out a home in minutes, but help from NGOs and the municipality takes days.
Our solution, Fireline, is built on Open Payments. Fireline enables community members, such as a church congregation, to join a community pool by contributing a monthly fixed fee of R30 (with an option to pay in advance). When a fire occurs, they can file a claim, which, when verified by other community members, provides a fixed payout of R800 directly to their wallet address – they can choose how to spend it according to their needs, such as replacing lost documents, buying a tarp, or food. The system is two-layered: single fires are funded by the member pool, and when multiple covariate fires occur and exhaust it, an externally funded backstop tranche is utilised. Since the church is already a trusted group, it provides a natural foundation of trust for the pool.
The solution:
Fireline is a web application built with a React + TypeScript frontend and a Node.js/Express backend, with the Open Payments protocol handling every movement of money in the system.
How it works, end to end:
Joining the pool.
A member registers with their wallet address and authorises a recurring contribution of R30 per month. This is done through an Open Payments outgoing payment grant. The member gives explicit, interactive consent for the contribution, and retains full control to revoke it at any time. Members can also choose to pay several months in advance.Funding the pool.
Contributions are received into the community pool's wallet as incoming payments, giving a transparent, auditable record of what the pool holds at any moment.Filing a claim.
When a fire destroys a member's home, they file a claim from their phone. The claim is lightweight by design, the last thing someone needs after a fire is a paperwork burden.Community verification.
Other members of the trusted group (for example, fellow congregants) verify that the fire occurred. Verification is social rather than bureaucratic, which is what makes it fast. The community already knows what happened. Once the verification threshold is met, the claim is approved.Payout.
The system creates an incoming payment on the claimant's own wallet address, obtains a quote, and executes an outgoing payment of R800 from the pool wallet to the claimant. The money lands in a wallet the member already controls, and they decide how to spend it via replacing an ID document, buying a tarp, buying food.The backstop tranche.
The pool balance is checked before each payout. When several fires occur at once and the member pool is exhausted, the system draws on a second, externally funded tranche so that covariate events don't leave members unpaid. This two-layer structure is what separates Fireline from a simple savings club.
Mentorship:
Our biggest technical challenge was the Open Payments grant flow itself, specifically, getting our heads around the sequence of grant -> quote -> outgoing payment, and handling the interactive consent step so that a member could authorise a recurring contribution in a way that felt simple on the front end while being correct underneath.
The mentors were central to getting us unstuck, without them this would have been an incredibly difficult challenge to solve technically. A huge thank you and shoutout to them for their time effort, and guidance!
Key insights:
Understand the problem before you touch the code. The time we spent on the problem, rather than the build, is the reason the solution held together.
Trust is the real infrastructure. The technology only works because the church community already trusts each other, we designed around an existing trust network instead of trying to manufacture a new one.
Divide and conquer. Splitting the work along our respective strengths, and being honest when we needed help, is what got us to a demo we were proud of.
What’s next?
We definitely think Fireline is an idea worth expanding and investing in more. However, as a team we do need to discuss and think about it more. The next step would probably be to test it in a real-world environment.
The help we'd most value:
Introductions to community organisations and NGOs already working in informal settlements, so we build with them rather than for them.
Guidance on the regulatory question where a community mutual-aid pool sits relative to South African insurance regulation, and how to structure it responsibly.
Continued technical mentorship from the Interledger community as we move toward a production Open Payments integration.
Funders or partners for the backstop tranche, which is the piece that makes the model resilient rather than fragile.
Top comments (0)