Can a carrier take back money it has already paid you?

Settlement control = whether the party who owed you can still reach the money after they have paid it

A vault can earn a genuine return and still fail to deliver it. The invoice can be real, the debtor can pay on time, and the capital can still fail to come back. Between the debtor paying and the vault being repaid there is a moment when somebody else is holding the money.

For SukukFi that moment is unavoidable, because of a deliberate decision about whose name is on the account.

Why the debtor pays the carrier and not SukukFi

The invoice belongs to the carrier. An Approved Debtor, typically a mobile network operator, buys wholesale voice traffic from a carrier it has dealt with for years. The commercial relationship, the contract and the traffic records all sit between those two parties. SukukFi is not one of them.

So when the debtor settles, it pays a bank account in the carrier's own name, exactly as it did before any financing existed. Three things follow from that.

The debtor changes nothing. Redirecting payment to an unfamiliar third party means new vendor onboarding, fresh compliance checks and delay, on an invoice cycle that already works.

The carrier's contracts stay intact. Supply agreements can restrict assigning payment to outside parties, and where they do, settling into the carrier's own account avoids disturbing terms agreed long before SukukFi arrived.

And SukukFi never receives the debtor's money. The fiat lands in an account belonging to the carrier. SukukFi's claim is to the proceeds, established by a deed of assignment executed before any funding, with a notice of assignment served on the debtor specifying where payment goes.

This is what it means to say SukukFi is an orchestration layer. It underwrites the debtor, funds the carrier, holds the assignment and directs where settlement is delivered. It does not sit in the flow of funds and take custody of anyone's fiat along the way.

The problem that design creates

Being outside the flow of funds is the right structure, and it has an obvious cost. The proceeds that repay LP capital arrive first in an account bearing somebody else's name.

If recovery from that point depends on the carrier cooperating, then LP capital is protected by goodwill. That is not a control an investor can rely on, and it is not one SukukFi is willing to describe as a safeguard.

The question is whether a ledger can hold both properties at once. Settlement that satisfies the debtor and the carrier's own contracts, and that the carrier still cannot claw back. Both candidate designs were built on the Keeta test network and then attacked to find out.

Design one: delegated authority over the carrier's account

The obvious approach, and the one usually proposed. Proceeds land in an account the carrier controls. The carrier grants the protocol spending rights over that account so capital can be recovered.

On testnet this works exactly as advertised. The protocol was granted access and spending rights, and successfully recovered 10,000 units from the carrier's account.

Then the carrier revoked the grant. The next identical recovery was refused by the network: does not have required permissions to perform action. One block. No notice. No recourse.

The protection in this design lasts precisely as long as the carrier's cooperation, which means it is not protection. It is an arrangement that works until the moment it is needed.

Design two: an account the carrier never controls

Keeta has a primitive called a storage account. SukukFi creates it and owns it outright. The carrier is granted one permission against the settlement token, STORAGE_DEPOSIT, and nothing else.

The carrier can pay in. That is the entire set of things the carrier can do.

What the network refused

Three attacks were run against the second design, each signed by the carrier's own key.

The carrier tried to withdraw the settled funds. Refused. The carrier tried to revoke the protocol's authority over the account. Refused. The carrier tried to grant itself withdrawal rights. Refused.

Eleven operations were tested in total and all eleven behaved as expected. One result was unexpected in a useful way: creating the storage account already carries withdrawal authority, so an explicit self grant is rejected as redundant. Fewer moving parts than the design assumed.

Why this matters for LP capital

The two designs look similar on a diagram. Both end with proceeds reaching the vault. The difference is who does the refusing.

In the first design, the protocol declines to abuse an authority it holds, and the carrier can withdraw that authority whenever it likes. In the second, the carrier has nothing to withdraw, because the carrier was never an administrator. The ledger refuses on its own account.

That distinction is the difference between a control an investor has to believe and a control an investor can test. Anyone can open the demonstration, press the buttons, and watch the network say no.

What this does not prove

This is a test network, and testnet tokens hold no value.

It says nothing about credit risk. A carrier that never pays at all is a different problem, addressed by underwriting rather than by permissions. This work covers only what happens after payment is made.

The fiat leg is unbuilt, and it is the harder half. The named bank account and the on-chain destination are two different things, and the open question is whether a fiat anchor can deliver from one straight into the other without a discretionary step by the account holder. Keeta's fiat partner can presently deliver only to accounts holding one of its certificates, and storage accounts cannot hold a certificate yet. Until that changes, the design described here is not available in production and nothing in it is live today.

What the experiment establishes is narrower and still worth having. When the ledger can be made to enforce settlement control, it does, and the enforcement is verifiable by anyone who wants to check.

Open the settlement demonstration and try to break it, or read the artifacts directly on the Keeta test network explorer.