Who owes whom after a P2P payment? Follow the money and obligations

Consider an illustrative payment: at 12:04, a customer transfers 10,000 currency units. The trader sees the credit, the operator sends the merchant a paid notification, and the store supplies the goods. Yet the entire 10,000 remains in the recipient’s bank account. Who holds the money, who owes the store, and what protects it if the trader disappears? One green status answers none of those questions.

P2P processing requires a clear distinction between moving money and creating obligations. A message can traverse the chain in a second while settlement happens that evening. In the interval, someone effectively finances everyone else. Unless that role is identified beforehand, the first delayed settlement will usually reveal it.

Define the operating model first

P2P can describe several different arrangements. On an exchange marketplace, a buyer and seller exchange fiat for a digital asset, with the platform administering the asset hold specified in its rules. In a licensed payment workflow, participants receive or transfer money within permitted roles. An informal network collecting transfers through third-party personal accounts is a separate arrangement with its own legal and banking risks. An API and a security deposit do not turn it into an authorized payment service.

The following is an illustrative, transparent collection model. Its contracts and banking arrangements permit the workflow; the recipient is disclosed; the operator is entitled to appoint that participant; and the customer understands the payment’s purpose. Here, “trader” means a contracted execution participant. Its duties come from the agreement. This does not imply that any particular exchange P2P marketplace permits collections for someone else’s store. The figures explain the mechanics rather than represent a provider’s pricing.

A reservation comes before the payment details

The merchant creates a 10,000-unit order. The operator records the order identifier, currency, amount, expiry and agreed pricing. It selects an eligible executor, checking the permitted payment method, account availability, limits and collateral. Capacity for that particular order is reserved at the same time. Only after successful reservation does the customer receive specific payment details and instructions.

Assume a merchant fee of 400, split into 150 for the trader and 250 for the operator. A completed payment leaves the merchant entitled to 9,600. If the trader retains its fee from collected funds, it will remit 9,850 to the operator. The agreement might reserve the full 10,000 or a different exposure amount. Our example uses 10,000: an explicit monetary reservation rather than an unspecified single slot.

No customer money exists in the workflow yet. The reservation limits further assignments to the trader; it neither proves payment nor creates revenue. An unused order may expire. The system must retain a record of the payment details it issued, because a customer can send the transfer after the screen has closed.

Bank receipt creates several distinct obligations

The customer transfers from an eligible funding source. The participant confirms receipt using bank records and checks the amount, currency and association with the order. In this model, the operator assumes its obligation to the merchant after that verification. This is an explicit contractual assumption: another provider might promise settlement only after receiving funds into its own account.

The trader now holds 10,000 in fiat and owes the operator 9,850. The operator owes the merchant 9,600. The 250 difference is the operator’s fee before its own costs, while 150 is the executor’s fee. The operator has a receivable from the trader and a payable to the store. This accounting event has not increased the operator’s bank balance.

The merchant notification carries a business meaning: payment has been recognized under the agreed rule, allowing fulfillment. The notification itself is not a bank transfer. Its identifier links to the order, receipt record, pricing version and time the obligation was recognized. A repeated notification must refer to the same recognition rather than create another 9,600 payable.

Where collateral sits in the picture

Suppose the trader posted collateral worth 30,000 in advance. It was recorded separately from customer collections. When payment details were issued, 10,000 of available capacity was reserved. Confirming payment does not necessarily release that reservation. If the trader still holds the collected fiat, the operator still has settlement exposure to it.

In this model, the reservation remains until the 9,850 remittance is confirmed and any other release conditions are satisfied. If a system restores all capacity immediately after the trader clicks received, without a separate debt ceiling, the same collateral can support an indefinitely growing unpaid debt. That is a different credit model, requiring separate limits and a deliberate decision to accept the exposure.

Collateral can be applied against an obligation only on the agreed basis. The debt must not be discharged twice through both an incoming settlement and a simultaneous collateral deduction. Both events must reference the same exposure. A frozen digital asset must also not be counted automatically as fiat available to pay the store.

Evening settlement closes the cash chain

The trader remits 9,850 through the agreed settlement route. The operator matches the actual receipt to the settlement register, reduces its receivable and releases the corresponding collateral if no other hold applies. It then pays the merchant 9,600. Once that payout is confirmed, the store’s payable is closed. The operator retains 250 before costs, and the trader retains 150.

If the operator paid the merchant at 12:10 but received the trader’s settlement at 18:00, its own available liquidity or another permitted financing source funded that five-hour-fifty-minute gap. The accounting obligations could balance throughout the interval while the operator’s cash balance fell. Saying everything is covered by deposits is therefore insufficient to establish an ability to pay on schedule.

In batched settlement, a single bank transfer may cover several orders, fees and previously agreed adjustments. Allocation follows the batch register. Searching for a transfer equal to one individual customer payment can generate a false alarm. Assigning the whole batch to the first similar order corrupts the remaining balances.

A different model consumes a working balance

Some arrangements use a prefunded working balance. Consider one separately: the trader starts with a 1,000 USDT claim on the operator, at an illustrative agreed rate of 100 settlement-currency units per USDT. After collecting 10,000 in fiat, the working balance is debited by 98.5 USDT, equivalent to 9,850. The trader’s claim on the operator falls to 901.5 USDT, while the collected fiat stays with the trader. The merchant is credited with a 9,600 settlement entitlement; the operator still needs suitable liquidity to make the actual payout.

This second model does not also require remitting the same 9,850 in fiat: economic settlement has already occurred by reducing the working claim. A separate fixed security reserve need not be consumed. Combining the two models would charge the trader twice. The internal balance may also be an ordinary, potentially unsecured claim against a company. An attractive dashboard does not establish segregated custody or an immediate withdrawal right.

When a router sits between the parties

A technical intermediary can transmit orders and statuses without receiving money or becoming the merchant’s debtor. PayStar, for example, explicitly describes expected-settlement calculation as a control function, leaving the PSP’s obligation under its direct agreement intact. Another chain requires its own role assessment. Several logos in a dashboard do not imply several independent liquidity sources.

If the operator in our first example pays such an intermediary 50 from its own 250, it retains 200 before other expenses. The merchant remains owed 9,600, while the technical-service fee creates a separate 50 obligation. A message about every payment may pass through the intermediary even though no customer funds do. Responsibility for routing and data is not equivalent to guaranteeing recovery of all funds.

Three breaks in the chain

If the trader confirmed receipt but settlement never arrived, the trader’s obligation remains open and the contractual recovery or collateral process becomes relevant. If the operator received settlement but did not pay the merchant, the unresolved obligation is with the operator, even though another participant handled the customer’s original transfer. If the store received a notification but no bank receipt can be substantiated, the team must establish how payment was incorrectly recognized, record a correction and allocate responsibility.

For every order, the system should reconstruct one connected answer: who received the customer’s money; who recognized payment and on what evidence; who currently owes funds; what secures that claim; and which actual transfer discharged it. Wherever this explanation substitutes the word partner for a named role and obligation, financial transparency ends.