How Korsie works, in plain words

Moving school money costs schools money. South African schools and their shops pay about 2.4% to 5.75% (VAT included) to collect money digitally: card machines at the low end, school payment apps on small payments at the high end, and fixed per-payment fees on top that hit small tuckshop sales hardest. They also juggle apps that don't talk to each other and still reconcile by hand every week. Each new till, supplier or school adds more admin and more fees, so the cost grows instead of shrinking at scale.

Korsie charges a flat 1%, settles every break in one payment, and reconciles itself. Parents get real spending controls, and family abroad can keep a child's wallet topped up within a budget they set. We're trialling in South Africa and building for schools across Africa.

Schools and their bursars, tuckshop operators, parents, families abroad who support a learner, and the suppliers who stock the tuckshop. Each person gets their own simple app, and the agents do the work in between.

No. Korsie runs on the XRP Ledger's test network, where the currency has no value. The learners, wallets and purchases in the demo are fictional, and the agents' software refuses to connect to any network other than testnet.

Book a demo and we'll run a school day for you live: taps at the till, a settlement window closing, a restock paid over x402 and a parent's top-up, with the agents working on testnet while you watch. The live demo moves testnet money and asks Node, Korsie's AI, so it's open to people we've invited, with a username and password.

A tap moves money inside Korsie's books straight away. Real money moves on the XRP Ledger when a window settles: one all-or-nothing payment to everyone the window owes.

Windows keep each learner's purchases off the public ledger (only totals appear), give tills that lost signal time to sync, let a parent dispute a tap before it settles, and give the bursar one settlement file per window to check against the ledger.

Windows are always open, weekends and evening events included. The Bell agent closes each one when the school's bell rings, an event ends, or it reaches the team's size or time cap, and opens the next one in the same moment.

One till sells for every shop at the school: the tuckshop, the uniform shop and event tickets, with sizes and ticket types as variants. The tuckshop's sales pay its supplier and the school's commission; a school-owned shop's sales go to the school. Each window still settles as one payment.

The till also records card payments taken on the shop's own card machine, and cash. They are signed and checked like wristband taps and counted for stock and reports, but Korsie never settles them: that money is already with the shop. The till and the bursar show what each way of paying cost: Korsie's 1% against card fees of 2.4% to 5.75%.

A parent links the learner's phone from the parent app with a six-digit code that lasts ten minutes. The phone makes its own signing key, which never leaves it, and from then on it can pay only from that learner's wallet.

At the counter, the till shows a QR code for the item. The learner scans it and taps Pay. The platform checks the till's signed request, the phone's signature, the parent's rules, and the daily limit or freeze the parent set for that phone. Only then does it take the money from the wallet, like a wristband tap, and the till sees the payment within a second or two.

A watch that taps to pay is planned for Wear OS watches with NFC, such as the Galaxy Watch. Apple Watch doesn't let other apps use its NFC chip this way, so iPhone users pay with the QR code.

Every learner wallet has one code, its wallet number, for every way in. In South Africa, parents pay rands by PayShap, instant EFT or card with the code as the reference, and the wallet is credited at once (simulated in the demo; in production a collection provider such as Ozow confirms each payment).

From anywhere else, money arrives at Korsie's one pay-in address on the XRP Ledger with the code as the destination tag: XRP or RLUSD from any wallet, or RLUSD from a licensed payment partner for someone who paid them by mobile money, a bank transfer abroad or a rand stablecoin. The ledger itself refuses a payment to that address without a code, so nothing arrives unlabelled.

The Swap agent takes it from there. It passes RLUSD straight on to the learner's wallet, converts XRP on the XRP/RLUSD pool in one payment whose price floor the ledger enforces, and sends money with a code no wallet has back to whoever sent it. XRP and RLUSD are live on testnet; no partner pays out RLUSD on the XRP Ledger yet, so in the demo a simulated partner does, with a real payment on the ledger.

Yes. A parent at a sports day or a visitor at a fair scans the same QR code and pays by PayShap or card, with no wallet and no sign-up. In the demo these payments are simulated; in production the sponsor bank confirms them.

The money goes into a guest wallet with no learner behind it, and settles with the window like every other sale, so the shop is paid in the same payment. Korsie keeps only the amount and how the visitor paid. The pay page shows what a card would cost the school, next to PayShap.

Node is Korsie's AI: the model every agent reasons with. For every decision, code lists the options and works out every amount, payee and fee. Node chooses one and explains why in plain words.

Node never writes a transaction and never sees a key. It can only pick from the listed options: its answer is checked against that list, so it cannot invent a payee or change an amount. Whatever it picks still goes through the policy engine and the signer.

Node is an AI, not a person, and the site always says so. We plan to let schools chat with Node while they set up, under the same rule: it can prepare a change, and a person signs it.

The document a person signs for each agent: who it may pay, how much per payment and per period, at what price, in which hours, and above what amount a person must approve first. The bursar signs the settlement agent's mandate, the tuckshop operator signs procurement's, and the family signs the allowance agent's. The Bell moves no money, so it has no mandate; the bursar sets its rules in its directive.

Anything above the approval threshold waits for the person who signed.

Alongside the mandate, the person who signed it can give the agent a team directive: rules that code enforces before anyone chooses (for example, only suppliers who deliver by tomorrow), plain-words guidance for Node, and a deterministic playbook.

A directive can only take options away. It can never add a payee, raise a limit or create an option, and every choice is checked the same way, whoever made it.

Each agent's directive decides. The default is to hold: the agent waits and says why. A team can instead have its playbook decide when Node can't be reached, or always. Every decision record names who decided and whether Node was unavailable.

An outage drill on the Agents page lets a team rehearse this live, without asking Node.

Supplier replies, invoices and incoming memos are treated as data, never as instructions. They are shown to Node fenced off as untrusted, and they can never add a payee or change a limit, because payees and limits come only from the signed mandate.

The guardian also screens invoices: one that claims to be from a known supplier but names a new account is blocked on arrival.

The guardian pauses an agent within seconds when something looks wrong, such as spending too fast or paying someone new. The signer then refuses to sign anything for that agent, and only a person can resume it.

People can pause agents themselves too, and a family can revoke the allowance agent's right on the ledger with one tap. Only the family can do that.

The guardian runs in a process of its own and holds no keys, so a crashed or busy agent never blinds it. If it isn't running, the agents' worker keeps watching instead.

Yes: the school reserve. Its own key is disabled on the XRP Ledger, and its signer list needs the bursar and the principal together, like a school bank account with two signatories. When the pool runs low, the settlement agent can only ask; each of them signs on the bursar page, and Korsie combines the two signatures and submits them. One signature on its own is refused by the ledger.

The pool itself takes money only from senders Korsie has verified: its own agents and verified families, each holding a Korsie credential, plus Korsie's platform account and the reserve. Anyone else's payment is refused.

Each agent's account carries its identity on the XRP Ledger. Its own DID points to its page on this site, and Korsie's platform account issued it a "KorsieAgent" credential, which the agent's account accepted. Every agent page checks all three in your browser.

Anyone can issue a credential with that name, so what counts is who issued it. The check compares the issuer with Korsie's published platform address, and our trust check on testnet shows a look-alike from another account being refused.

It asks the right person, once, and says what to do. A family's allowance account running short goes to the family, with a button to add funds (or a parent can top up instead). A till that hasn't synced since the bell goes to the tuckshop operator. A payment over an approval threshold goes to the person who signed the mandate, who approves or declines it. A paused agent goes to whoever can resume it.

The bell at the top of every page counts only these, not every payment. Each person also sees what needs them on their own page. When the problem goes away, by their fix or any other way, the agent closes it and says what fixed it, so nothing is left hanging.

In the demo this all happens on the site. Email, SMS or WhatsApp messages come with sign-in after the pilot, so Korsie only holds a person's contact details once they have an account.

No. Its stock budget is a payment channel funded from the tuckshop operator's own account, and the ledger refuses any claim beyond what the operator put in.

We tried four ways around it on testnet: overdrawing the channel, the agent adding to its own budget, opening a budget from the operator's account, and claiming with the wrong key. The ledger refused all four.

The tuckshop operator adds to or closes the stock budget from the till app. The person who signed a mandate changes its limits on the agent's page: per payment, per period, the approval threshold and the hours, but never its payees. The signer checks every payment against the latest version.

The family revokes or restores the allowance agent's right from the family app.

Every decision has a page showing what the agent saw, the options, why it chose, every policy check and the ledger result. Your browser recomputes the record's seal and reads the memo straight from a public XRPL server. If the two hashes match, the record hasn't changed since the payment was made.

You can also paste any transaction hash into Check a transaction on the decisions page.

RLUSD is Ripple's US dollar stablecoin. Korsie uses it, from Ripple's testnet issuer, as the settlement and cross-border currency, standing in for a regulated rand stablecoin. Korsie never creates a token or any other asset.

A Batch bundles a break's payments to the tuckshop, the supplier, the school, Korsie's fee and the feeding round-up into one transaction that succeeds or fails as a whole, so nobody is ever half paid.

The settlement agent also checks every inner payment's result, because a successful Batch doesn't by itself mean every payment in it went through.

The family abroad grants the allowance agent one right on the ledger: to send Payments from the family's account. The agent signs with its own key, never the family's. Only the family can revoke the grant, and once they do, the ledger refuses the agent's next payment.

Delegation limits the kind of transaction, not the amount. The amount is limited by the mandate, and by funding the family's account only with its budget.

XRP that one account sets aside on the ledger for another. The tuckshop operator funds procurement's weekly stock budget this way. The agent draws from it with claims signed by its own key, and the ledger never pays out more than the operator put in.

Only the operator can add to it or close it, and what isn't spent goes back to them.

An open way for software to pay for a request over the web, using the HTTP 402 Payment Required status. When the procurement agent orders stock, the supplier's API answers with its terms. The signer checks them against the agent's decision, the agent pays exactly that on the XRP Ledger, and T54's testnet facilitator verifies and settles the payment.

The ledger's automated market maker swaps between XRP and RLUSD. The treasury agent uses it to buy the XRP that Korsie's fee accounts need, within a price limit set in its mandate.

The acting agent's SourceTag, and a memo with the agent's ID, the action, the task and a SHA-256 hash of the full decision record. The record itself is kept off the ledger and published, so anyone can check that the two match.

In the demo, the Swap agent puts every deposit into the pool as RLUSD, and the learner's wallet is credited in rands at a fixed demo rate of R17.50 a dollar. Korsie's finance lead publishes that rate on the XRP Ledger as a price oracle, the agents credit at what the ledger says, and the wallet and Swap pages read it from the ledger in your browser. The pool's RLUSD stands in for the rands a sponsor bank would hold, and settlement pays the shop and school from it.

In production, a licensed partner converts the money as it arrives and pays rands into the school's pooled account at the sponsor bank, and the wallet is credited with what actually arrived. VALR, licensed by the FSCA, pays rands out to South African bank accounts, and Yellow Card collects mobile money and bank payments in about 20 African countries. Neither yet supports RLUSD on the XRP Ledger, so the partner step is planned, not built.

It matters because sending money home is expensive: the World Bank measured an average cost of 8.46% to send $200 to Sub-Saharan Africa, and 15.65% to send it from South Africa, against a global target of 3% (third quarter of 2025). South Africa's exchange-control rules for crypto assets are being redrafted, so the cross-border step waits for the final rules.

A flat 1% of what goes through Korsie, paid by the shop or school as one payment in each window's settlement. Card and cash taken on the shop's own machine cost nothing extra and earn Korsie nothing. Parents topping up by PayShap pay their bank's usual fee. There is nothing to pay during the testnet beta.

The school report shows what the school saved against card fees of 2.4% to 5.75%.

Korsie's own idle reserve does. When the treasury agent's fee budgets are full, it can put idle RLUSD into the XRP Ledger's XRP/RLUSD pool, which pays its liquidity providers a share of a 0.5% fee on every swap. Its mandate names that one pool and caps the position, and Node decides, knowing that moving in and out costs about 0.5% and that half the position moves with the XRP price.

Learners' balances and the school's money are never invested. A school could put its own reserve to work the same way under its own mandate, and in production a rand reserve earns interest at the sponsor bank.

Parents can choose to round each purchase up to the next rand. The difference goes to Korsie NPC's feeding scheme, paid in the same settlement as everything else.

No. The XRP Ledger is public and permanent, so names, student numbers, grades, allergies and dietary blocks never go on it. Learners appear only as an opaque wallet number, and agents refer to them by that number when they ask Node to choose.

Nothing. The trial runs on the XRP Ledger's test network, so no real money moves.

We start with a conversation about how money moves at your school today. Then we set Korsie up for you on testnet: tills, learner wallets and mandates your own people sign. You use it, and tell us what works and what doesn't.

Sign up on the beta page, or email support@bitrora.com.