-
-
Logo
-
Logo
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 recipient-initiated, sender-authorised, and automatically routed through the best compliant rail — without the awkward phone call?
St4bl was built to remove the shame from family remittance.
Recipients request support when they need it. Senders stay in control with pre-authorised rules. Qwen interprets the request, ARP enforces the rules, and the system routes the safest compliant transfer.
Mum does not have to ask. You do not have to wonder.
What it does
St4bl is a Telegram-first family-support agent for diaspora remittance, built on the open-source Agent Remittance Protocol / ARP.
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. Qwen parses the request, extracts the structured intent, and passes it into ARP’s deterministic financial workflow.
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, the transfer is staged and executed through compliant partner infrastructure.
If it is outside policy, the sender is asked to approve first.
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 combines:
Qwen3.5-Flash for natural-language understanding and workflow reasoning
ARP for deterministic policy enforcement
rail comparison for EUR→KES routing
M-Pesa payout logic
sender-defined family-support rules
append-only audit logging
The family sees a simple bot.
The system underneath is an AI-powered remittance autopilot with hard financial guardrails.
How we built it
We built St4bl as an Autopilot Agent using Qwen as the reasoning layer and ARP as the deterministic execution layer.
The core principle is:
Qwen reasons. ARP enforces.
Qwen is allowed to understand the user’s intent, extract structured payment context, select the next workflow step, and explain the route.
Qwen is not allowed to move money directly.
The St4bl workflow:
- Request
The recipient messages the Telegram bot with a natural-language request, such as:
“Request KES 2,000 for groceries.”
- Qwen Intent Parsing
Qwen3.5-Flash extracts the structured intent:
recipient
amount
currency
purpose
urgency
requested payout method
- Policy Check
ARP 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
ARP 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 through approved partner rails. If it falls outside policy, the sender is asked to approve first.
St4bl is built on:
Qwen3.5-Flash for agent reasoning
Telegram as the recipient and sender interface
ARP as the deterministic remittance protocol
MCP-style tool boundaries for agent-accessible workflow steps
a policy engine for sender-defined family-support rules
rail adapters for EUR→KES routing
M-Pesa payout logic
append-only audit logging
execution locks and idempotency keys to prevent unsafe retries
The AI makes the experience conversational.
The protocol makes the financial execution safe.
Challenges we ran into
Making Qwen safe enough for financial workflows
LLMs are probabilistic. Payments cannot be.
The biggest challenge was designing a system where Qwen could understand intent and coordinate the workflow, but never independently move money outside deterministic rules.
We solved this by separating reasoning from execution.
Qwen can interpret a request, classify it, extract structured intent, and recommend the next step. ARP decides whether the action is allowed. Execution only happens when the sender’s pre-authorised policy allows it or when the sender explicitly confirms.
That distinction is fundamental.
Qwen proposes. ARP enforces. The user remains in control.
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 say:
“I need an agentic remittance protocol.”
They said:
“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 unsafe automation
The easy version of this product would be a chatbot that says, “Sure, I’ll send money.”
That is not safe enough for fintech.
We deliberately built St4bl as a constrained workflow:
Qwen handles language and reasoning
ARP handles rules and state
execution is bounded by sender policy
out-of-policy requests require approval
all events are auditable
The result is an autopilot agent with brakes.
Accomplishments that we’re proud of
A real Autopilot Agent use case
St4bl is not a generic chatbot.
It automates a real-world business workflow: diaspora family support and remittance.
The workflow starts with ambiguous human input and moves through intent parsing, policy validation, quote comparison, optimisation, staging, approval, execution, and audit logging.
That makes it a strong fit for the Autopilot Agent track.
Qwen-powered reasoning with deterministic enforcement
We are proud of the architecture boundary.
Qwen makes the system intelligent and conversational.
ARP makes it safe and auditable.
That means the model can help users express intent naturally without giving the model unrestricted control over money movement.
A sharper consumer wedge
We moved from a protocol-first product to a family-support product.
The infrastructure still matters, but the user does not buy protocol.
The user buys peace of mind.
The clearest expression of St4bl is:
Recipients request support. Senders pre-authorise rules. Qwen understands the request. ARP finds the safest compliant route and executes only when allowed.
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
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
no direct model-controlled money movement
What we learned
AI belongs in orchestration, not custody
The most important lesson was that Qwen should not be the money mover.
Qwen should be the reasoning layer.
It translates messy human requests into structured workflows, but the backend must enforce the financial rules.
That separation made the system safer, more explainable, and more suitable for fintech.
The best fintech products start with behaviour, not infrastructure
Our early framing focused on technical rails, protocols, and AI middleware.
But the strongest insight came from 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 powerful when it disappears
Users do not need to see the AI.
They need the outcome.
The best use of Qwen in St4bl is behind-the-scenes orchestration:
understanding intent
extracting structured context
selecting the next workflow step
explaining a route clearly
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
why the system made a decision
Automation only works when the boundaries are clear.
What’s next for St4bl.com
Complete the Qwen Cloud deployment path
Our immediate hackathon focus is to make the Qwen-powered Autopilot Agent easy for judges to understand, run, and inspect.
Next steps:
document the Qwen3.5-Flash runtime
show the Qwen intent-parsing flow
demonstrate ARP policy enforcement
provide a code walkthrough
publish the architecture diagram
deploy the backend on Alibaba Cloud / Qwen Cloud where required for the submission
Prove the EU→Kenya family-support wedge
Our commercial focus 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 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 or regulated digital currency through partner infrastructure and convert only when support is actually needed.
The same Dignity Pull flow remains:
recipient requests support
Qwen parses the request
ARP checks policy
only the needed amount is converted
money arrives through 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 workflow:
recipient request
AI intent parsing
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.