Free of Payment Settlement
A settlement instruction that transfers an asset without a simultaneous payment leg, exposing the delivering party to principal risk until payment is separately confirmed.
Definition
What is free of payment settlement?
Free of payment (FoP) settlement is the transfer of a security or digital asset without a simultaneously linked payment leg. The delivering party releases the asset — securities, tokens, or collateral — and the receiving party does not simultaneously release cash in the same instruction. Payment, if required, is handled separately through a bank wire, ACH instruction, or a second transaction on a different rail.
FoP stands in contrast to delivery versus payment, where the asset and payment leg are atomically linked and settle simultaneously. DvP eliminates counterparty risk by ensuring neither party is exposed to the other's default between delivery and payment. FoP removes that protection by design.
FoP is not inherently problematic — it is the appropriate settlement method when no monetary consideration is changing hands, or when the business rationale for decoupling the legs is documented and controlled. The operational risk lies in uncontrolled or undocumented FoP instructions treated as standard settlement flow.
Institutional use cases for FoP settlement
Four categories of institutional activity legitimately use FoP instructions:
Collateral pledging. When a firm posts margin to a repo counterparty, prime broker, or central counterparty, it transfers securities without receiving immediate payment — an inter-depository transfer that is FoP by structure. The collateral is encumbered rather than sold, so no payment leg exists. The firm recovers the securities when the underlying obligation is released. Firms operating under margin frameworks such as FINRA Rule 4210 must ensure FoP instructions for collateral posting are linked to specific margin calls or obligation records in the audit trail.
Internal book transfers. Moving assets between accounts or wallets owned by the same legal entity — cold storage to a trading wallet, one custodian account to another within the same firm — involves no external counterparty and no payment. These transfers are FoP by definition. They still require SSI validation and audit trail documentation to distinguish them from inadvertent external transfers.
Custody migrations. When a firm moves a portfolio from one custodian to another, assets transfer in bulk without payment — a class of inter-depository transfer where FoP is the only structurally appropriate instruction type. The receiving custodian is not purchasing the portfolio; they are accepting it on behalf of the same beneficial owner.
Gift and estate transfers. Gifting securities or distributing estate assets to beneficiaries involves no monetary consideration. The transfer is FoP, and tax implications are handled separately through cost basis elections and gift reporting under applicable tax reporting frameworks.
Principal risk and the FoP control framework
Principal risk in FoP is the exposure to losing the full value of a delivered asset if the counterparty defaults between delivery and payment. Unlike counterparty risk in a pending trade — where neither party has moved yet — FoP principal risk is realized at the moment of transfer. The delivering firm has given up the asset and holds only an unsecured claim on the counterparty for payment.
The control framework for FoP operates across four layers:
SSI validation. Before any FoP instruction is released, the destination account must be validated against standing settlement instructions. An unvalidated or modified destination is the most common vector for settlement fraud and misdirected transfers. SSI validation must occur at instruction entry, not at release.
Maker-checker approval. FoP instructions above a defined notional threshold require four-eyes review — an independent approver must confirm the business justification before the instruction is released. The threshold and approval workflow must be documented in written supervisory procedures.
FoP audit log. Every FoP instruction must be logged with the business justification, approver identity, timestamp, and outcome. Regulators examining operational risk management frameworks expect evidence that FoP instructions were reviewed and justified, not simply executed under standard settlement controls.
Orphaned transfer detection. A FoP instruction without a corresponding payment confirmation is an orphaned transfer — an asset has left the firm with no record of payment received. Exception management workflows must identify and escalate orphaned transfers within the settlement day before end-of-day reconciliation closes.
FoP in the digital asset context
Every standard ERC-20 transfer() or SPL token transfer call is structurally equivalent to a FoP instruction. The token moves from one wallet to another with no linked payment leg — the blockchain has no native concept of simultaneous settlement legs unless a smart contract enforces them. This creates accidental FoP exposure for firms that move tokenized securities, stablecoins, or real-world assets using standard token primitives without DvP wrappers.
A common misconception is that the ERC-20 approve() / transferFrom() pattern provides a settlement control. It does not — approve() grants a third party permission to pull tokens, but the pull itself is still an asset movement with no simultaneous payment. The result is a two-step FoP, not DvP. True on-chain DvP requires a dedicated settlement contract — such as a hashed timelock contract or a purpose-built DvP escrow — that holds both legs simultaneously and releases them atomically in a single transaction.
Beyond operational risk, FoP-plus-wire settlement also carries a capital efficiency cost. During the lag between asset delivery and payment confirmation, the delivering firm's capital is frozen: the asset is gone and the cash has not arrived. In 24/7 digital asset markets, this window can span multiple settlement cycles across time zones. Atomic DvP using a regulated payment stablecoin eliminates the lag entirely — asset and payment clear simultaneously, and the received cash is immediately redeployable without a waiting period.
Until full migration to atomic DvP is complete, every digital asset transfer must be treated operationally as FoP — classified, justified, and logged under the same controls applied to traditional securities.
FoP vs DvP — settlement path comparison
Devancore Glossary · devancore.com
FoP vs DvP — settlement path comparison
Devancore Glossary · devancore.com
How it works
How FoP settlement works — step by step
1. Instruction classification. When a settlement instruction is received or generated, the operations system classifies it as FoP or DvP based on the presence or absence of a linked payment leg. Instructions without a cash amount, payment rail, or atomic settlement contract reference are classified as FoP and routed to the FoP exception workflow rather than the standard STP pipeline.
2. SSI validation. Before release, the destination account or wallet address is validated against the standing settlement instructions database. Any instruction destined for an account not on the SSI whitelist is held for manual review. On digital asset rails, the destination wallet address is cross-referenced against the approved counterparty address book. Validation must complete before the instruction advances to approval.
3. Business justification and maker-checker review. The operations team records the business justification for the FoP instruction — collateral pledge, internal transfer, custody migration, or estate transfer — and routes it through the maker-checker workflow if the notional value exceeds the defined threshold. The approver confirms the justification, the counterparty, and the validated destination before releasing the instruction.
4. Asset transfer. The instruction is released and the asset is transferred — securities through the custodian or CSD, tokens through the blockchain network. At this point, the delivering party carries full principal risk exposure. The asset has been delivered; the payment has not been confirmed.
5. Payment confirmation or orphan detection. If a payment is expected, the system monitors for a corresponding cash receipt — wire confirmation, blockchain transaction hash, or ledger credit. In traditional markets, orphaned transfers are typically surfaced at end-of-day reconciliation. On 24/7 digital asset rails, the monitoring window is rolling: an alert fires when a FoP instruction has been outstanding beyond a configurable time threshold, without waiting for a daily batch cycle. The instruction is flagged as an orphaned transfer and escalated to trade break management for resolution.
6. Audit log entry. Whether the FoP instruction results in a confirmed transfer or an orphaned transfer, the event is logged in the FoP audit trail. The log entry includes: instruction type, counterparty, destination account, asset and notional, business justification, approver identity, release timestamp, and payment confirmation status. This log is the primary evidence for regulatory examination of FoP controls under written supervisory procedures.
In Devancore™
FoP-to-DvP transition pipeline
Devancore Glossary · devancore.com
FoP-to-DvP transition pipeline
Devancore Glossary · devancore.com
FoP settlement in Devancore
Devancore classifies every settlement instruction at capture and routes FoP instructions through a dedicated control layer before release.
FoP instruction classification. When a settlement instruction is captured — manually entered, FIX-sourced, or imported from a custodian file — Devancore checks for a linked payment leg. Instructions without a payment amount, payment rail, or atomic contract reference are classified as FoP and flagged in the instruction queue. The FoP classification is visible to operations staff and cannot be overridden without a recorded justification.
Intent matching and rail enforcement. When a front-office system marks a trade as DvP but the selected settlement rail can only execute FoP — such as a standard token transfer without a DvP contract — Devancore generates a hard block. The instruction cannot be released as FoP when the trade record requires DvP settlement. The operations team must either select a DvP-capable rail or reclassify the instruction with explicit approval, creating a documented exception in the audit trail.
SSI whitelist validation. Before a FoP instruction can advance to maker-checker review, Devancore validates the destination account or wallet address against the standing settlement instructions registry. Unmatched destinations generate a hard block — the instruction cannot proceed until the destination is confirmed or added to the SSI registry with full approval documentation. On digital asset rails, wallet address validation includes format verification and counterparty binding.
Maker-checker approval with notional thresholds. FoP instructions above the configured notional threshold are routed to the maker-checker workflow queue. The approver sees the full instruction context — counterparty, destination, asset, notional, business justification, and SSI validation status — before approving or rejecting. Instructions below threshold are auto-approved with a logged audit entry. Thresholds are configurable per asset class and counterparty type.
Daily FoP velocity limits. Devancore applies configurable daily FoP volume thresholds per desk, asset class, or counterparty. When cumulative FoP notional in a rolling 24-hour window approaches the configured limit, operations supervisors receive an automated alert. If the limit is breached, further FoP instructions require Chief Compliance Officer approval until the threshold resets. This control is particularly relevant on 24/7 digital asset rails where FoP activity does not pause at end of business day.
Business justification codes. Every FoP instruction is tagged with a standardized business justification code before release. Standard codes include: Internal_Vault_Move (intra-firm wallet or account transfer), Collateral_Pledge (margin or repo posting), Custody_Migration (inter-depository transfer between custodians), Estate_Transfer (gift or estate distribution), and Exception_Approved (other reason documented and approved by a supervisor). The code is stored in the audit log and used to generate FoP activity reports by category for FINRA and SEC examination.
FoP audit log with real-time orphan detection. Every FoP instruction generates a structured audit log entry including classification reason, SSI validation result, business justification code, approval chain, release timestamp, and payment confirmation status. The FoP audit log is exportable for regulatory examination and satisfies documentation requirements under written supervisory procedures. Orphaned transfers — FoP instructions without a corresponding payment confirmation — are detected in real time, not at end-of-day batch. Devancore issues an alert when a FoP instruction has been outstanding beyond the configured time threshold, surfacing it in the exception dashboard and linking it to the trade break management workflow without waiting for a daily reconciliation cycle.
FoP-to-DvP conversion. For counterparties capable of atomic settlement, Devancore offers a FoP-to-DvP conversion workflow. When a FoP instruction is detected and the counterparty SSI includes a DvP-capable settlement address or contract reference, the system prompts the operations team to restructure the instruction as DvP — adding the payment leg and routing through the atomic settlement contract. This workflow supports the gradual migration from legacy FoP-plus-wire settlement to atomic on-chain DvP as counterparties and custodians modernize their settlement infrastructure, without requiring a hard cutover.