What centuries of payments, promises and disputes can teach developers building systems in the AI age.

Traditional banking didn't evolve on the assumption that humans were trustworthy. Much of its machinery exists because they aren't.

People lie, forget, steal, mistype account numbers, lose documents, die and occasionally get their sums spectacularly wrong. Institutions do all of those things too, usually with more paperwork.

Now add software that can imitate a familiar voice, produce convincing correspondence or act on someone's behalf. The old problem of deciding whom to trust acquires more ways to go wrong, and more opportunities to go wrong quickly.

The October 2026 Binance breach is a particularly expensive reason to think about the whole system. Binance, a service where customers buy, sell and store cryptocurrency, reported approximately $6.34 billion in affected assets and said it would absorb the financial impact. Customers' recovery depended on the company's resources and actions, beyond whatever guarantees the underlying transaction records provided.

I'm not a finance expert. I'm a software developer who has worked with, and read, people much smarter about this subject than I am. What interests me here is what their work can teach us about designing systems that survive contact with people.

One example is hawala, a way to send money through a network of brokers who trust one another. You pay a broker in one place; their counterpart pays your recipient elsewhere from money already available locally. The brokers sort out what they owe each other separately. We'll walk through an example shortly.

The design question is the one I want to explore: how do you build a system with hawala's ability to function through disruption and banking's layers of security, accountability and recovery?

Neither has a single property we can simply copy. Hawala can survive some infrastructure failures while remaining vulnerable to particular people. Banks provide substantial controls and remedies while sometimes excluding the people who most need a service. My work with Amanacard, a former customer, brought those tensions into the same design.

Medieval merchant banks, hawala brokers and even an illegal online drugs market offer useful evidence. Each found ways to make commerce work between people who had excellent reasons to distrust one another. Their answers put trust in different places, and put the bill for failure in different hands.

Resilience means being able to survive mistakes, including mistakes made by people your system was supposed to protect.

Debt starts with what people owe one another

Before following a payment, it helps to ask what it represents. If I supply your shop today and you agree to pay me next month, you have a debt and I have a claim: your promise to pay is something I expect to collect. Credit lets you obtain something now and pay later; debt is the obligation left to fulfil.

Anthropologist David Graeber's Debt: The First 5,000 Years challenges a familiar origin story: people first swapped goods directly, invented money to make swapping easier, and only later developed credit. Graeber argues that relationships of credit and obligation long predated minted coins. His interview with Philip Pilkington explains the distinction between a general sense of owing someone a favour and an obligation measured as an exact amount.

That argument concerns the history of money; it doesn't mean nobody ever bartered, or that every society followed one sequence. The useful shift for this discussion is to start with relationships and obligations, rather than imagine finance began as a succession of isolated cash purchases.

A ledger is a record of balances and transactions. It might be a book, database or shared digital record. It helps answer how much is owed. The surrounding society still has to answer why it is owed, whether the claim is legitimate and what happens if someone cannot pay.

Graeber also puts enforcement and forgiveness at the centre of the story. In his interview with Alex Bradshaw, he describes how debt could threaten people's freedom, and how societies used measures including debt cancellation to address the resulting crises. His wider argument is that the treatment of debt reflects political power and moral choices as well as arithmetic.

Haiti provides a particularly brutal example of debt imposed through power. After a revolution against slavery and French colonial rule, Haiti declared independence in 1804. In 1825, France demanded 150 million francs as the price of recognising that independence, backed by warships and the threat of a blockade. The payment was an indemnity, meaning compensation: it was destined for former colonists, including former slaveholders, for the property they claimed to have lost. France was demanding payment from the society that had escaped enslavement to compensate those who had profited from it. The French foundation for the memory of slavery reproduces the original ordinance, including its payment conditions.

Haiti then had to borrow on the French financial market to meet the first instalment. That created a second obligation: repay the loan used to pay the imposed debt. Although the indemnity was reduced to 90 million francs in 1838, the payments and associated borrowing continued to drain public resources. Historian Gusti-Klara Gaillard-Pourchet's account published by France's national library also describes France making recognition of subsequent Haitian governments conditional on bringing overdue payments up to date. Debt gave the former colonial power a continuing means of pressure after independence.

This was an enforced financial obligation created under military threat, rather than an ordinary loan freely chosen to fund something useful. Calling it a debt made it recordable and collectible; that didn't make its origin just.

For a developer, the distinction matters: a system can keep accurate accounts and enforce an unjust obligation perfectly. Recording a rule, deciding whether it is legitimate and providing a way to challenge it are different responsibilities. Automating collection doesn't settle those questions.

That helps explain why financial systems contain both enforcement and exceptions. They need dependable promises, but also ways to handle broken promises without making continued participation impossible. Who gets an exception, and who must absorb the loss, remains a question of power.

Hawala, banking and Bitcoin make different choices about those responsibilities. Their records matter, but so do the people and institutions entitled to interpret or change the consequences.

When trust travelled through people

Start with a merchant who needs to pay someone in another country. Carrying coins across the intervening roads and seas creates obvious problems. Replacing the coins with a promise creates a different one: whose promise will the recipient accept?

Late medieval merchants already had sophisticated answers. A bill of exchange was a written instruction arranging for someone to be paid elsewhere, often later and in another currency. It connected a payment in one place with an obligation in another.

Quinten Metsys, The Moneylender and His Wife (1514), Louvre Museum. Reproduction from The Yorck Project via Wikimedia Commons, public domain.

Historians James Bolton and Francesco Guidi-Bruscoli examined nearly 2,000 bills and related documents from the Borromei banks' fifteenth-century records. They found a network using family banks and trusted correspondents: people or businesses handling transactions on the bank's behalf elsewhere. Entries in account books often replaced movements of coin. Payment arrangements could also be adjusted by agreement, including extensions and instalments. These were working relationships with room for negotiation. Their account of the research is a useful antidote to the idea that financial sophistication began with computers.

Think about what a correspondent supplied. A distant merchant might be a stranger to you, but known to someone whose judgement you had relied on before. That person could introduce them, vouch for them or put their own money at risk.

The relationship carried information that a single transaction couldn't: previous dealings, connections, the prospect of future business and the consequences of behaving badly.

The same person who could recommend you could stop recommending you. A profitable network could become inaccessible after a sufficiently serious betrayal.

This wasn't a world without institutions or law. Family firms, contracts, courts and personal relationships overlapped. Nor is there a neat historical ladder from personal trust to banks to software. These mechanisms coexist because they solve different parts of the problem.

That becomes especially clear with hawala.

Hawala separates payment from settlement

The brokers in a hawala network are commonly called hawaladars. One common use is a remittance: someone working abroad sending money to relatives at home.

Settlement means making good on what one party owes another. In this example, the recipient gets paid first; the brokers settle their own debt separately.

Cash and a mobile phone in Kabul, 2010: the ingredients for communicating an instruction and making a local payout. The photograph provides context rather than documenting a particular hawala transfer. Photograph by Jan Chipchase, via Wikimedia Commons, CC BY-SA 3.0, reproduced unchanged.

Here is a simplified example, with the fee and exchange rate agreed in advance:

1. A worker in London gives a broker £500.
2. The broker instructs a counterpart in Pakistan to make a payment.
3. That counterpart pays the recipient the agreed amount in local currency from funds available locally.
4. The brokers record an obligation between themselves and settle it separately.

The recipient doesn't need to wait for those particular pounds to travel to Pakistan. The International Monetary Fund's remittances guide describes this separation between the customer's transfer and brokers balancing obligations over time.

sequenceDiagram
    participant S as Sender in London
    participant A as London broker
    participant B as Broker in Pakistan
    participant R as Recipient
    S->>A: Pays £500 plus agreed fee
    A->>B: Requests agreed local payout
    B->>R: Pays from local funds
    Note over A,B: B now has a claim on A
    A-->>B: Settle what remains owed separately

Suppose the London broker later pays a different customer on behalf of the Pakistani broker. That creates an obligation in the opposite direction. Some of the amounts can cancel out, a process called netting. If one broker owes the other £500 and is owed £300 back, they can settle the £200 difference. Whatever remains owed still has to be paid.

The Financial Action Task Force, an international body working against money laundering, describes settlement through cash, trade and netting in its study of hawala and similar providers. It also distinguishes legitimate, hybrid and criminal providers. Hawala describes a mechanism used in varied settings, rather than a single organisation or an automatic synonym for crime.

The architectural distinction is simple but powerful: making a payment available and settling the intermediaries' obligations are separate operations.

For the recipient, local availability matters. For the brokers, managing the outstanding balance matters. The recipient can get paid quickly because the paying broker accepts the risk of being owed money by the other broker.

Why the broker pays

Why would a broker hand out money before receiving settlement?

Because the instruction comes from a relationship with a history. A counterpart who consistently honours obligations is useful. Someone who refuses to settle can lose access to future business.

Research on trust and social control in informal value transfer systems treats these as distinct mechanisms: expecting someone to cooperate and being able to impose consequences are different things. Its computational model explores how continuing interactions and social control can sustain cooperation. That is an explanation of possible mechanisms, rather than a guarantee about every real network.

Imagine the broker deciding whether to keep one customer's money. The immediate gain has to be weighed against future earnings, relationships and whatever sanctions the network can impose. Honesty can be commercially rational even when dishonesty is technically possible.

The difficult case is someone whose incentives change. A person who expects to leave the business may value tomorrow's reputation much less than today's opportunity. A previously reliable broker may also run out of money to meet their obligations without intending to cheat anyone.

Past cooperation is evidence. It doesn't give you something you can seize or sell to recover a loss.

What relationships can and cannot repair

Hawala's separation of local payout from later settlement can be useful where access to conventional banking is limited. The US Financial Crimes Enforcement Network describes legitimate family remittances as a common use.

But think through the failures this arrangement exposes. If one broker disappears, their counterpart still has customers and outstanding obligations. Negotiation may help when the relationship survives; it does much less when the person or the money is gone.

Informal enforcement also raises an awkward question: who gets heard? A powerful member may find it easier to obtain a concession than an isolated customer. Pressure that disciplines a dishonest broker can become coercion. Network membership can provide access while leaving outsiders excluded.

Legal status and customer protection depend on the country and provider. A personal assurance doesn't establish a fund to compensate customers if the business fails, or give them an independent complaints process.

Hawala distributes work across brokers while placing substantial risk in particular relationships. We should ask which failures those relationships can absorb, and which ones they amplify.

Amanacard and the unexpectedly useful loyalty card

This is a problem I've worked on. Amanacard is a former customer of mine. I worked with them on the design of their system to help people in conflict zones receive secure payments when conventional banking couldn't reach them.

The company was founded and led by Dr Edwina Thompson, an international expert on hawala and financial flows in conflict zones. Her experience working with informal remittance networks and humanitarian organisations was central to the approach. A 2020 biography from the Graduate Institute in Geneva describes how she brought those fields together to establish Amanacard, supporting payments to hospitals, schools, displaced people and businesses in Syria and Iraq.

In architectural terms, the system I worked on ended up looking surprisingly like a supermarket loyalty card. One of our partners was the UK's biggest provider of those systems at the time. That comparison sounds rather less dramatic than financial infrastructure for a war zone, but it captures something useful about the design.

A card identifies an account. The account has a recorded balance. Participating merchants recognise it, and spending the points, called redemption, reduces that balance. Familiar retail machinery can support something far more consequential than a discount on the weekly shop.

A February 2020 report in The Times, reproduced by Amanacard, describes cards loaded digitally with points that people could spend in participating shops or convert into cash through a hawala agent. The recorded value and the local means of honouring it worked together. The digital balance didn't make the local merchant or broker unnecessary.

For refugees and displaced families, and for people continuing to work in conflict zones, the practical requirement was access to money or essentials. For Western donors, another requirement was evidence that their support reached the intended people, rather than being diverted to Assad's regime or other people and organisations they were legally restricted from funding. Those requirements had to meet in the same system.

The challenge was to make local delivery accountable to a distant funder. Who was entitled to receive support? Who actually received it? Which merchant or broker honoured the balance? Could the records be checked against what happened on the ground?

The European External Action Service's description of a 2021 Amanacard event captures that problem explicitly: supporting health, education and cash assistance in Syria while building the confidence of banks and donors through independent financial monitoring.

The doctors behind the payment records

There is a direct connection to For Sama, the 2019 documentary directed by Waad al-Kateab and Edward Watts. It follows Waad's life, family and the war in Aleppo, including her husband Dr Hamza al-Kateab's work caring for patients under bombardment.

Hamza subsequently worked as operations manager at Huozhi/Amanacard. His Action For Sama biography describes the organisation's support for health workers, health facilities and displaced families. The film shows the human circumstances behind the need for payments; his later work connects those circumstances to the delivery system.

Paying a doctor matters. So does paying the cleaner, porter or supplier whose work keeps a hospital functioning. A functioning payment arrangement lets people continue doing that work and support their own families.

This is where the loyalty-card comparison becomes an architectural lesson. The interesting achievement was combining a familiar account-and-redemption mechanism with local relationships, verification and records that funders could scrutinise.

That gave donors a basis for confidence about delivery. It wasn't a claim that software could prove every participant honest or eliminate every possibility of diversion. The assurance depended on the quality of the checks and the people performing them.

Amanacard made trust more inspectable while retaining the local networks needed to deliver value. The software, the merchants, the brokers and the people checking recipients each had a job. Removing the human relationships would have removed much of the system's ability to function.

Banking gives promises an institutional home

Modern banking makes it possible to rely on people you will never meet. Your payment can pass through organisations whose staff, owners and systems you know very little about.

The promise belongs to an institution that can outlive its employees. Records, contracts, supervision and legal obligations help that promise survive changes of personnel.

That promise is quite literal. Money in a bank account is a claim on the bank: the bank owes you the recorded amount. It isn't a labelled pile of your banknotes in a drawer. The Bank of England's introduction to money in the modern economy explains bank deposits as a form of IOU. Modern banking makes those promises usable for everyday payments between people who don't know one another.

The history wasn't a clean break with personal commerce. NatWest's historical account describes English banks growing out of goldsmiths' and merchants' businesses. The familiar institution accumulated around existing commercial relationships.

Its controls address different problems:

Mechanism in plain English	The problem it helps address
Double-entry bookkeeping: record each transaction in balancing entries across accounts	Catching some missing or inconsistent entries
Reconciliation: compare records kept separately, such as your ledger and a bank statement	Discovering missing, duplicated or disputed transactions
Clearing and settlement: work out what institutions owe one another, then pay it	Completing payments across institutions
Fraud controls	Detecting suspicious or unauthorised activity
Dispute procedures	Examining contested payments and commercial claims
Deposit protection: compensation for covered account balances if a bank fails	Protecting eligible customers from certain bank failures
Supervision and audits: outside scrutiny of institutions and their records	Checking compliance and looking for problems

None is a universal defence. Balanced books can contain fraud. An audit doesn't insure every customer. Deposit insurance doesn't make a bad purchase refundable.

The value comes from addressing several failure modes rather than expecting one mechanism to solve them all.

Someone still has to carry the loss

The United States created the Federal Deposit Insurance Corporation (FDIC) in 1933; its programme to protect covered bank deposits began in January 1934. It emerged from a banking crisis in which people with bank accounts had good reasons to fear losing their savings. The FDIC's historical timeline places that protection in its proper context: an institutional response to institutions failing.

Depositors outside banks on 28 February 1933, after withdrawals were restricted. Confidence can fail collectively even when each person is trying to protect their own savings. Franklin D. Roosevelt Library collection / US National Archives, photographer uncredited, via Wikimedia Commons, public domain in the United States.

The important conceptual change is that an eligible depositor's recovery needn't depend entirely on the failed bank's remaining assets. A wider arrangement takes responsibility, within defined coverage rules.

That doesn't eliminate loss. It changes who pays and when. It might fall on an insurance fund, the bank's owners, others it owes money to, or a government rescue. Each arrangement changes the consequences of taking risks.

Likewise, friction has more than one purpose. A check can interrupt a scam; a badly designed check can exclude a legitimate customer. A delay can allow investigation; it can also be the residue of an inefficient process.

The useful question is what a control prevents, how often it works and what it costs the people subject to it.

Final settlement and customer remedies are different layers

Banking isn't a giant undo button. Final settlement means the payment has completed under the system's rules and cannot simply be recalled by the sender. The Bank of England describes CHAPS, the UK's system for high-value payments, as providing irrevocable payments. Its settlement service transfers balances between participating institutions' accounts at the central bank.

Yet a customer may still have a claim under the payment service's rules, a contract or the law. The UK's Financial Conduct Authority describes several routes for recovering fraudulent payments, with different eligibility conditions. A chargeback, for example, is a process through which a card provider seeks a refund from the seller's bank. A legal claim or compensation for a qualifying scam follows different rules.

That distinction matters technically. A remedy can create a new payment or compensate a victim without erasing the original settlement record.

A system can preserve history and still repair its consequences.

Silk Road built trust around pseudonyms

The original Silk Road operated from approximately 2011 until 2013. It was an illegal online marketplace, heavily associated with drug sales. People accessed it through Tor, software that routes connections through several relays to help conceal their origin, and paid using Bitcoin, a digital currency with a publicly shared transaction record called a blockchain.

It helped popularise Bitcoin by giving people a concrete reason to acquire and spend it. That doesn't mean it accounted for most Bitcoin activity: Nicolas Christin's contemporary measurement study explicitly cautioned about estimating its share of the wider economy.

Its appeal included the possibility of buying without handing conventional payment details to a merchant. But Bitcoin was pseudonymous, not inherently untraceable: a payment used an address rather than directly displaying a legal name. Tor helped conceal network connections. Neither property guaranteed that a person's activity could never be linked back to them.

Bitcoin's own guidance on privacy explains that transactions are public and that identities can become associated with addresses. Once a link is established, earlier activity may become informative too.

The irony is substantial: a currency associated with anonymous commerce leaves a durable public payment history.

But Silk Road had a more immediate problem. Paying for something illegal didn't make the seller deliver it. A buyer complaining about missing drugs couldn't expect an ordinary consumer dispute to proceed normally.

A marketplace needs more than proof of payment

Silk Road supplied seller histories, feedback, escrow and operator mediation. Escrow means a third party holds the buyer's payment until agreed conditions are met. Here, Silk Road held the money until the buyer confirmed the purchase was complete, called finalisation. Its operators also helped resolve disputes. Established sellers could ask buyers to release the money before delivery, transferring more risk to the buyer. Christin's study describes the mechanism.

The US government's diagram of Silk Road's payment system, introduced at Ross Ulbricht's trial. The escrow and commission sit inside the marketplace, between buyer and seller. US Government exhibit 113 A, via Wikimedia Commons, public domain in the United States; reproduced unchanged.

The difference is between two questions:

Did the payment happen?

Did the seller do what they promised?

Only the first is answered by the payment ledger. Someone still has to assess claims about a parcel, its contents or its arrival.

An operator mediating those claims becomes a trusted party. Holding the funds creates another dependency: customers need the operator to remain honest, able to pay what it owes, secure and available. That responsibility for holding other people's assets is called custody.

Hawala and Silk Road therefore share a useful structural feature. A successful participant has something to lose by cheating. For a hawaladar, that may be access to established relationships; for a seller using a pseudonym, it may be the future earning power of an account.

That is a comparison of incentives, without suggesting that the two systems have the same purpose or social setting.

Durable identity doesn't have to mean a public name

Can you build durable trust without durable identities?

You can build it without everyone knowing a legal name. A persistent pseudonym can accumulate a commercially valuable history. An account that has traded successfully for years is different from a new account making the same promise.

But continuity has to mean something. If a banned participant can cheaply return with equivalent standing, exclusion loses force. If an established account is sold or stolen, the history remains while the person controlling it changes.

Research by Bhaskar, Linacre and Machin on online drugs markets found that poor ratings were followed by reduced sales and sellers leaving the market. It also examined the 2015 exit scam at Evolution, another marketplace whose operators disappeared with users' funds. Reputation can discipline individual traders while leaving customers exposed to the platform holding their money.

There is a further weakness in any such incentive: a valuable reputation can make a final betrayal more profitable. Past honesty helps someone attract the funds they might eventually steal.

The ledger worked while the application failed

In September 2012, James Zhong exploited Silk Road's withdrawal processing. According to the US Department of Justice's account, he deposited 500 bitcoin (BTC) into one account, then made five withdrawals of 500 BTC in rapid succession. The broader scheme obtained more than 50,000 BTC.

Bitcoin didn't have to accept an invalid transaction for Silk Road to lose money. The application paid out funds it shouldn't have released.

In November 2021, investigators recovered roughly 50,676 BTC from Zhong's home. The DOJ credited cryptocurrency tracing alongside conventional investigation. This was recovery through investigation and access to assets, rather than a reversal of the blockchain.

Three separate properties are visible here: a ledger can record transfers correctly, an application can authorise the wrong transfers, and investigators can later recover assets through powers outside that ledger.

Calling all three “blockchain security” conceals the distinctions that matter.

Bitcoin makes finality a deliberate choice

Bitcoin tackles a difficult problem: agreeing on a transaction history and preventing double spending, where someone tries to spend the same digital money twice, without appointing one central ledger operator.

The original white paper explicitly discusses the cost of mediation and the attraction of payments that are computationally impractical to reverse. It also envisages escrow to protect buyers. The need for commercial protection was there at the beginning.

Here, finality is how confident a recipient can be that a payment will stay completed. Bitcoin groups transactions into blocks. As further blocks are added after the one containing your payment, it becomes harder to replace that part of the shared history. These are confirmations. Replacement, called a chain reorganisation, remains possible, so the guarantee is probabilistic. “Mathematically irreversible” overstates it.

What is absent is a native customer dispute process that decides an otherwise valid transfer should be undone because it was mistaken or fraudulent.

One of its greatest strengths is also one of its greatest weaknesses: a valid transfer is hard to undo regardless of whether the human intended it.

That protects a recipient against arbitrary reversal. It also protects a thief's completed transfer from being reversed merely because the victim can prove theft.

A private key is a secret used to produce a digital signature authorising a transfer. The network checks that signature against its rules. A valid signature doesn't establish informed consent, ownership under the law or fulfilment of a contract: an attacker who obtains the key can also produce one.

This is why the public ledger's traceability doesn't automatically rescue a victim either. Knowing where value moved is different from controlling it. Recovery may require a cooperative recipient, an intermediary able to freeze assets, access to keys or legal enforcement.

The original transaction can remain final while a later intervention changes who possesses the assets.

Trust moves between layers

These systems aren't direct substitutes. Banking is a broad institutional system, hawala a family of transfer arrangements, Silk Road a marketplace and Bitcoin a payment protocol. Comparing their trust boundaries is more useful than scoring them as competing products.

System or layer	Where reliance sits	How failure may be addressed
Consumer banking	Institutions, payment rules and legal remedies	Investigation, reimbursement or compensation where applicable
Hawala	Brokers and continuing relationships	Negotiation, settlement and network sanctions
Silk Road	Account reputation, escrow and operators	Mediation or exclusion, with substantial custody risk
Bitcoin's underlying payment network	Signature checks and rules for agreeing on a shared history	No built-in consumer reversal; recovery needs additional mechanisms

“Trustless” can describe a reduction in specific dependencies. It cannot tell you everything about the service a person is actually using.

A person holding their own keys takes on responsibility for keeping them safe. A person using an exchange relies on that exchange to hold their assets, keep accurate accounts and control withdrawals. Adding escrow introduces rules for releasing funds and possibly someone to decide disputes. Multisignature arrangements require more than one key to authorise spending, but people still have to choose who controls those keys and how disagreements are handled.

These are architectural choices about who can act, who can refuse and who can repair a failure.

We remove an intermediary, then discover that some of its jobs still need doing.

When the trust boundary reaches a developer's laptop

Binance's initial findings published on 3 November 2026 describe a campaign involving social engineering, compromised engineer devices, an internal AI tool and stolen deployment credentials. The attacker reached an internal wallet-signing service and initiated transfers outside the normal withdrawal process. Binance says its investigation remains ongoing and subject to independent review.

The architectural implication is that the ledger can enforce its rules while the surrounding service authorises a catastrophe.

“It's only as secure as a developer's laptop” captures the problem if the authority reachable from that laptop can ultimately move customer assets. The more useful design requirement is to ensure that compromising the laptop doesn't also compromise every subsequent decision.

Protecting key material is one job. Controlling what a signing service will sign is another. A signature can be cryptographically valid while the instruction that caused it is fraudulent.

That is why putting keys in specialist hardware, or distributing signing across several machines, cannot by itself establish that the customer intended a payment. If all the participants accept instructions from the same compromised service, they share a failure mode.

The same question applies to banks, aid platforms and AI agents: how far can one compromised identity, device or service take an attacker?

Combining local resilience with institutional safeguards

The historical examples suggest a design direction: distribute the ability to deliver a service, bound the authority of each participant, and make the resulting obligations independently checkable.

For an AI-assisted payment service, I would start with the following separation. This is a proposed architecture, rather than a description of Amanacard's implementation.

flowchart TD
    R[Request and supporting evidence] --> A[AI helps interpret and prepare]
    A --> P[Independent identity and policy checks]
    P --> V[Required approval bound to payment details]
    V --> E[Executor with limited authority]
    E --> L[Local payout or settlement]
    L --> C[Independent reconciliation and recipient checks]
    C --> D[Disputes and funded recovery]

Keep local delivery possible when infrastructure fails

The lesson from hawala is that a recipient can be paid locally while intermediaries settle separately. A useful modern system should preserve that option where the setting requires it.

Suppose an aid programme needs to pay clinic workers during a connectivity outage. Before the outage, it could reserve funds for a specific payroll batch and assign a capped payout allowance to an approved local provider. That provider could honour the authorised batch within its limits and submit receipts when connectivity returns.

Offline operation introduces real risks. The same entitlement mustn't be independently assigned to several providers that cannot communicate. Each payment needs a unique identifier, retries mustn't create a second obligation, and ambiguous payout status needs investigation before another payment is issued. Reconciliation can discover conflicts; it cannot retrospectively prevent someone handing out cash twice.

That means accepting limited exposure to keep essential work going, with explicit rules about its size and who bears it. Unlimited offline spending would turn resilience into an unlimited credit facility for an attacker.

The fallback provider also needs liquidity: enough money available now to make the payments. It needs a viable route to the recipient too. A replicated database cannot manufacture either.

Separate recognition from permission

A familiar voice or a persuasive message can help a conversation. Neither should grant payment authority. In an AI-assisted workflow, establish who is acting, whom they represent and exactly what they may do through an authenticated mechanism outside the conversation.

The US National Institute of Standards and Technology (NIST) explores these questions in its February 2026 draft concept paper on agent identity and authorisation, including delegated authority, least privilege and links between agent actions and human authorisation. It is a proposed programme of work, not a finished guarantee for agent security.

In practical terms, delegation means letting software act on someone's behalf; least privilege means giving it only the permissions needed for that job.

My practical rule would be to give an agent authority for a defined task, with an expiry, approved recipients and aggregate spending limits. Access to a conversation or document shouldn't expand that authority. An invoice asking the agent to change a supplier's bank account remains evidence to assess, rather than permission to make the change.

Make approvals independent and specific

An AI can extract invoice details, translate a recipient's message or flag a suspicious pattern. The service enforcing payment policy should check the structured action against authoritative records and limits, even if the model confidently recommends it.

For higher-risk actions, bind approval to the actual recipient, amount, currency and purpose. Changing those details should require a new approval. A generic “yes, continue” is poor evidence of consent when the action can change afterwards.

Separate the powers to enrol a recipient, alter their destination, approve a payment, deploy the executor and override its limits. Two approvals offer little protection if the same compromised administrator can manufacture both.

This is also where a developer's laptop should encounter a hard boundary: permission to deploy software shouldn't automatically grant permission to redefine the rules that release customer funds.

Use independent evidence to reconcile what happened

The Amanacard example distinguishes recording a redemption from verifying delivery to the intended person. A consistent database needs evidence from outside itself when its entries represent events in the world.

Compare the authorised obligation, the executor's record, the provider's settlement account and evidence of receipt. Those records need protection from being rewritten together by the party under examination. Four reports generated from one compromised database don't constitute four independent checks.

AI can help find mismatches and prioritise investigation. A second model reading the first model's explanation is a weak substitute for a separate record of what actually happened.

Recipient verification must also protect the recipient. A donor needs evidence of delivery; they don't necessarily need a public list identifying vulnerable people, their locations and their payments.

Design containment and recovery before release

Bound exposure per transaction, per participant and over time. Ten thousand individually permitted payments can still be a catastrophe. Monitor aggregate outflows and retain a way to suspend the affected authority without shutting down every unaffected provider.

Revocation has to reach the authority that can still act. Stopping new requests doesn't cancel instructions already accepted elsewhere, and an offline provider cannot instantly learn that a credential was revoked. Expiries and capped allowances limit what can happen during that gap.

Then define the remedy. Who investigates a disputed payout? How does a recipient challenge an incorrect decision? Who can authorise compensation, and which reserve, insurance arrangement or contractual obligation funds it?

Graeber's question returns here in practical form: who has the power to enforce an obligation, and who has the power to release someone from it? Giving an AI authority to refuse or demand payment also requires deciding how the affected person can challenge that decision.

An append-only record can retain the original payment and a later compensation. Preserving history needn't condemn a customer to its consequences.

Keep a person's reputation contestable

Hawala and Silk Road both make continued participation valuable. A modern system can use that history while recognising that accounts are stolen, staff change and previously reliable organisations fail.

Assess reputation for a particular activity and level of exposure. A provider's success with small payments doesn't establish that it can safely handle an unlimited payroll. Provide an appeal when a flag or model judgement excludes someone from essential services.

The aim is continuity with accountability: enough local discretion to operate through disruption, enough independent control to contain abuse, and a credible remedy when the controls fail.

Designing for people in the AI age

Hawala offers lessons in local knowledge, continuing relationships and separating delivery from settlement. Banking offers lessons in bounded authority, reconciliation, oversight and remedies. Amanacard brought those concerns together around a practical requirement: people needed to get paid, and funders needed evidence that the right people received the value.

AI makes some of that work easier. It can help interpret messy records, bridge languages and find discrepancies. It also gives attackers more ways to imitate the signals people use to recognise one another, while automation can turn a mistaken judgement into many actions.

The design challenge is to let useful work continue when a connection fails, a device is compromised or a model is wrong, without giving that failure permission to spread everywhere.

A system hasn't achieved much resilience if it keeps running while the people relying on it lose everything. The test is whether essential service can continue, damage can be contained, and someone has both the authority and resources to put things right.

Build for the day a trusted person, laptop or AI agent fails. The rest of the system should still know what it owes, whom it owes it to, and how to make good.