⚠️ NOTE TO HACKATHON ORGANIZERS & ARIZE JUDGES ⚠️ Due to a submission form error before the deadline lock, this project was accidentally miscategorized under the GitLab track, pls change it to ARIZE
Inspiration
Every month, diaspora families send money home for school fees, groceries, medical bills, rent, emergencies, and small business support.
But the real pain is not just the transfer fee.
It is the moment before the transfer.
A mother in Nairobi needs help but waits days before calling her son in Berlin because she does not want to feel like a burden. A sister needs money for groceries but hesitates to ask again. Meanwhile, the sender opens multiple remittance apps, compares rates manually, worries about hidden FX markups, and still does not know whether they picked the best route.
Remittance apps have made sending money faster.
But they have not solved the emotional burden of asking.
That insight became the foundation for St4bl.
We asked a simple question:
What if family support could be pre-authorised, recipient-initiated, and automatically routed through the cheapest compliant rail — without the awkward phone call?
St4bl was built to remove the shame from family remittance.
Recipients can request support when they need it. Senders stay in control with pre-set rules. The AI agent finds the best route and executes only when the request fits the sender’s policy.
Mum does not have to ask. You do not have to wonder.
What it does
St4bl is a Telegram-first family-support bot for diaspora remittance.
It allows senders in Europe to pre-authorise support rules for trusted family members in Kenya. A recipient can then message the bot when they need help. If the request fits the sender’s rules, St4bl automatically finds the cheapest available rail and executes the transfer through compliant partner infrastructure.
Example:
“Request KES 2,000 for groceries.”
St4bl checks:
Is this recipient approved? Is the amount within the sender’s weekly limit? Which rail delivers the most net value after fees and FX? Are there M-Pesa withdrawal tier costs to avoid? Does this request require manual confirmation or can it execute automatically? If the request is within policy, money is sent.
No awkward call. No manual rate-checking. No guesswork. No shame.
The recipient gets support when they need it. The sender gets control, transparency, and peace of mind.
Under the hood, St4bl compares live rails, optimises the transfer route, calculates recipient-side costs, and keeps a secure audit trail. But to the family, the product feels simple:
A trusted support bot that makes sure help arrives when it is needed.
How we built it
We built St4bl as a deterministic financial workflow with an AI orchestration layer on top.
The core principle is:
Agent proposes. Human disposes. Code enforces.
The AI is allowed to understand intent, compare options, and recommend the best route. It is not allowed to move money outside the sender’s approved rules.
The St4bl workflow:
Request The recipient messages the Telegram bot with a natural-language request, such as: “Request KES 2,000 for groceries.” Policy Check St4bl checks the sender’s pre-authorised rules: approved recipient maximum amount weekly or monthly limits permitted payout method whether manual confirmation is required Quote The system queries available rails and calculates total cost, including fees, FX, settlement speed, and recipient-side withdrawal charges. Optimise St4bl identifies the route that delivers the highest net value to the recipient, including M-Pesa tier optimisation where relevant. Stage The transfer is staged with a clear breakdown of amount, route, fees, recipient, and expected delivery. Execute If the request fits the sender’s policy, execution can happen automatically. If it falls outside policy, the sender is asked to approve first. St4bl is built on:
a Telegram-first user interface a policy engine for sender-defined family support rules rail integrations for EUR→KES routing M-Pesa payout logic a secure audit trail for staged and executed transactions AI-assisted intent parsing and route recommendation deterministic backend enforcement so the AI cannot bypass rules The AI makes the experience feel conversational.
The backend makes the financial execution safe.
Challenges we ran into
Making AI safe enough for money movement
LLMs are probabilistic. Payments cannot be.
The biggest technical challenge was designing a system where the AI could understand intent and recommend actions, but never independently move money outside deterministic rules.
We solved this by separating reasoning from execution.
The AI can interpret a request and propose a route. The backend decides whether that route is allowed. Execution only happens when the sender’s pre-authorised policy allows it or when the sender explicitly confirms.
That distinction is fundamental to St4bl.
Designing for dignity, not just efficiency
At first, the product was framed around route optimisation and protocol infrastructure. That was technically correct, but emotionally wrong.
Users did not describe the problem as:
“I need an agentic remittance protocol.”
They described it as:
“I wish my mum could ask without feeling bad.” “I want to know she has what she needs.” “I do not want to compare three apps every time.”
The challenge was simplifying the product around the real human job-to-be-done.
That led to the Dignity Pull: recipient-initiated support inside sender-approved rules.
Handling fragmented rail behaviour
Remittance and mobile-money rails do not behave uniformly. Fees, FX rates, response times, limits, and recipient-side withdrawal costs vary across providers.
We had to build routing logic that does more than compare headline transfer fees. It calculates what matters most:
How much does the recipient actually receive and keep?
That required factoring in both sender-side and recipient-side costs.
Avoiding premature platform complexity
The original architecture could support a broader protocol, multiple corridors, and B2B integrations. But building everything at once would dilute the wedge.
We made a deliberate product decision:
Start with one corridor. One interface. One emotional use case. One measurable behaviour.
EU→Kenya. Telegram. Family support. Recipient request.
Accomplishments that we’re proud of
Live product, not just a concept
St4bl is not just a slide deck. We have built a working Telegram-based flow with real rail integrations for the EUR→KES corridor.
The system can process a family-support request, check sender-defined rules, compare available routes, stage the transfer, and execute through partner rails.
A sharper consumer wedge
We moved from a protocol-first product to a family-support product.
That was a major breakthrough.
The infrastructure still matters, but it is no longer the story we lead with. The user does not buy protocol. The user buys peace of mind.
The clearest expression of the product is now:
Recipients request support. Senders pre-authorise rules. St4bl finds the cheapest rail and executes safely.
Recipient-side optimisation
Most remittance products focus on the sender. St4bl also optimises for the recipient.
That means accounting for local payout behaviour, M-Pesa withdrawal tiers, and what the family member actually receives after all costs.
The goal is not just to send money.
The goal is to maximise useful support.
Safe-by-design financial automation
We are proud of the safety architecture.
St4bl does not give the AI unrestricted payment authority. Every transfer is constrained by explicit policy, deterministic checks, and auditability.
The system is designed around trust:
sender control recipient dignity clear limits traceable execution no unauthorised movement of funds What we learned
The best fintech products start with behaviour, not infrastructure
Our early framing focused on the technical layer: routing, protocols, rails, and AI middleware.
But the strongest insight came from the user behaviour.
People do not just send money. They manage responsibility, guilt, timing, trust, and family expectations.
Once we understood that, the product became much clearer.
The recipient is the hidden centre of remittance
Most remittance products are designed around the sender.
But in family support, the recipient often knows the need first.
St4bl flips the flow. The recipient can initiate the request, while the sender keeps control through pre-authorised rules.
That creates a more natural support loop.
AI is most valuable when it disappears
Users do not need to see the AI. They need the outcome.
The best use of AI in St4bl is not a chatbot gimmick. It is behind-the-scenes orchestration:
understanding intent checking policy comparing rails recommending the best route reducing manual work The user experience should feel simple, not futuristic.
Trust beats speed
Instant transfers are valuable, but trust is more valuable.
In family finance, users need to know:
who can request how much can be sent when approval is required what rail was used what the recipient received Automation only works when the boundaries are clear.
What’s next for St4bl.com
Prove the EU→Kenya family-support wedge
Our immediate focus is not multi-corridor expansion. It is proving that diaspora users will pay for the Dignity Pull.
The next milestone is simple:
10 paying strangers 50 paying users 70%+ month-two retention 200 paying users and €1k MRR If we can prove that families use St4bl repeatedly, we earn the right to expand.
Launch Treasury as a Phase 2 feature
The next product layer is St4bl Treasury.
Today, families often send early or hold value in local currency “just in case.” That can expose them to FX movement and purchasing-power loss.
Treasury will allow senders to hold value in hard currency through regulated partner infrastructure and convert only when support is actually needed.
The same Dignity Pull flow remains:
recipient requests support St4bl checks policy only the needed amount is converted money arrives via the best available route Treasury is not a separate product. It is an upgrade to the same family-support system.
Expand to additional African corridors
Once the EU→Kenya wedge is proven, St4bl can replicate the model across other high-friction diaspora corridors.
Priority expansion candidates include:
EUR→NGN EUR→GHS GBP→KES EUR→UGX Each corridor reuses the same core product:
recipient request sender policy rail comparison local payout optimisation audit trail Build the family-support layer for diaspora finance
The long-term vision is bigger than one transfer route.
St4bl can become the trusted family-support layer for diaspora households: a place where recurring support, emergency requests, school-fee payments, medical support, and treasury decisions are managed through one simple interface.
But the path starts narrow.
One corridor. One bot. One wedge. One truth:
Mum should not have to ask. You should not have to wonder.
Log in or sign up for Devpost to join the conversation.