The flow catalogue

An escrow transaction is a sequence of desks, and the order of those desks is the product. It opens as a request from a client or as a transaction Wolf configures directly, becomes a numbered version of terms that an Authorised Signatory at each company has to accept, and only then produces funding instructions. Money arriving against those instructions passes two different tests before it counts for anything: Operations reconciles it against the requirement, Compliance clears it. Performance is evidenced against the release conditions written into the accepted terms, and when the last of them has passed, one Wolf seat prepares the payout and a different one approves it.

No seat carries a transaction through that on its own, and none of the handovers is a formality. Each of them is also a place where a transaction can stall, be corrected, be held or be contested, which is why so much of what follows is about what the product does when the straight path does not hold.

The catalogue is those places, driven through the real product rather than described. 17 flows carry a transaction the whole way. The other 44 isolate a single move on the same transactions, for a reader who wants one mechanism without the story around it.

Escrow NEW is one escrow product read from four perspectives. A single transaction record is presented to the Buyer, the Seller, Wolf Operations and Wolf Compliance, and each of the nine seats inside those four sees the same facts with different authority and different visibility. It implements the state model of Escrow Product Documentation 2.0 in full: the state dimensions are shown together rather than collapsed into one status word, funding finality is kept separate from settlement finality, FX is completed before anything is treated as secured, milestones secure and release on their own, release runs under a four-eyes control, holds and disputes freeze money without pretending to decide the commercial question, and every funded tranche carries a 60-day custody clock.

The demonstration data is fourteen seeded transactions, labelled A to N, each shaped to put the product in a position worth inspecting: a clean fiat transaction, a crypto to crypto transaction, an FX shortfall, mixed milestone states, an overpayment, an outstanding external verification, a compliance alert immediately before payout, a rejected payout, a split dispute, a variable final amount above and below the secured maximum, and a custody limit reached during a dispute.

The workspace is organised as a dashboard, a work list, a transaction list, a transaction detail with eight tabs, and a set of Wolf operating surfaces: the work queue, escrow creation, funding and reconciliation, the FX desk, verification, release approvals, settlement monitoring, compliance cases, custody clocks and the audit trail. Client seats reach the dashboard, their own work list, the transaction list and detail, their documents, and their requests and messages; the operating surfaces belong to Wolf. Content differs by seat on every shared surface, rather than the surface being duplicated per role.

A transaction begins either as a client request or as a Wolf-initiated escrow. Both routes lead to the same place: a terms version that names the parties, the amounts, the currencies, the payout destination, the release conditions and the fee schedule.

The terms are then accepted by both companies. Acceptance is by an Authorised Signatory on each side, in either order, and funding instructions are not issued until both acceptances exist. This is the first hard gate in the product, and it is why the funding tab is empty for a transaction that is still awaiting a signature.

Funding follows. Money arrives against dedicated instructions, is reconciled against the requirement, and is cleared by compliance. Only then does the transaction reach Funds Secured. Performance and verification run against the release conditions written into the accepted terms: evidence is uploaded and approved, external verifiers return results, the Buyer gives the confirmation the terms ask for, and the Seller submits Request Release where the terms include one.

When every condition is satisfied and the full amount is secured, the transaction becomes ready for release. A release instruction is prepared by one Wolf seat and approved by another, then submitted to the rail. Completion is not the approval and not the submission: a transaction completes when the partner reports finality and a matching ledger debit exists.

The terminal outcomes are completed, cancelled and refunded, partially settled and cancelled, and expired unfunded. A resolved dispute is not itself a terminal outcome: the financial result still has to be one of those four.

An escrow transaction cannot be described by a single status word. A transaction can be fully funded and blocked, commercially complete and unpaid, disputed on part of its value and settling normally on the rest. The product therefore carries six independent state dimensions and displays five of them on the header of every transaction at once, with the sixth attached to each milestone.

No dimension is stored. All six are recomputed from the command history every time the record is read, which is why no two screens can disagree about the same transaction.

The contractual terms exist as versions, never as an editable document. Each version carries a number, a hash, an author, a creation time, a status of draft, awaiting acceptance, accepted, superseded or expired, and the acceptance record of each side. An acceptance names the company, the individual who gave it, their role, the exact version identifier, the hash of what they accepted and the authentication context in which they gave it.

Fields within a version are classified. Contractual fields are the ones whose change requires a new version and fresh acceptance. Operational and internal fields are recorded on the version for completeness but do not carry that consequence. Where a version amended a field, the previous value stays on the record beside the new one, so a reader can see what changed without reconstructing it from two documents.

Acceptance is order independent and idempotent. Either side may go first, and a repeated acceptance is a no-op with an explicit message rather than a second event. There is an acceptance deadline on the version, surfaced on the transaction header and in the work queues.

Once accepted, the version is immutable. There is no edit path anywhere in the product. The only way to change an accepted term is to publish a new version through the amendment path, which is why the terms tab explains that asking for a change is how an amendment starts, rather than presenting change as an inline edit.

A change request is the entry point to an amendment and it is available at any live stage of the transaction. It is blocked only once the transaction is closed. This is deliberate, and it corrects an intuition that costs users an hour: a change requested after both companies have accepted is not refused, it is precisely the case the amendment path exists for.

Publishing an amendment creates a new terms version, marks the previous one superseded, records the amendment reason, and invalidates both acceptances. Both companies then accept the new version, in either order, exactly as they accepted the first.

A completed milestone is not reopened by an amendment. Milestones carry an immutability marker, and a milestone that has already been released and reconciled stays as it settled while the remaining milestones move to the new version.

Publishing an amendment is a lifecycle event for compliance, not only for the contract. It opens a re-screening case and says so in the audit entry. A material change to parties, amounts, destinations or conditions is exactly the kind of change screening exists to catch, so an amendment that changed the terms without touching the compliance position would be a hole in the control rather than a convenience.

Before any money has been received, the party who raised the request may withdraw it. The withdrawal is recorded and the transaction ends unfunded. Once funds have been received the withdrawal control is refused, because there is now client money in a dedicated structure and unwinding it is a movement, not a retraction.

After Funds Secured there is no unilateral cancellation. A cancellation at that point rests on a joint authenticated instruction from both Authorised Signatories, is cleared by Compliance, and still needs a maker and a separate approver like any other movement. It produces a refund instruction that defaults to the asset actually secured and returns it to the verified source.

A closed transaction is not unwound. Joint cancellation is refused on a terminal transaction both in the interface and in the engine, so the refusal does not depend on the screen being right.

The inverse case is worth stating because the first build had it backwards. After finality a party may still record a complaint, and the dispute control stays available for that purpose with wording that says the settlement is final and nothing freezes. Recording a grievance after the money has moved is allowed; reversing a settled transaction is not.

A release condition is the contractual sentence that has to be true before money moves, and it is stored and displayed as the exact wording from the accepted terms. It is never paraphrased into a shorter label, because the sentence is what the parties agreed and a summary of it is not.

Every condition names its authoritative source. The verifier is the Buyer, the Seller, Wolf Operations, a named external verifier with a provider, or a trusted system event with the system named. Only that source can satisfy the condition, and this is enforced in the engine and not only in the interface: recording an external verifier result against a condition whose verifier is Wolf Operations is refused.

Conditions carry a logic group and an AND or OR relationship inside it. Grouping is what lets a transaction say that a certificate of analysis from either of two named laboratories will do, while the bill of lading and the customs clearance are both required. Readiness for release is evaluated over the groups, not over a flat checklist.

Each condition also carries the operational detail that decides what happens when things do not go to plan: its deadline, its failure rule stating the consequence if the condition fails, and where relevant its no-response rule stating what happens if the party who owes the answer is silent. Both are shown on the condition itself rather than living in a policy document.

Conditions can be scoped to a milestone, in which case they are grouped under that milestone with its own amounts and its own custody clocks. A transaction with no conditions at all cannot become ready for release.

Where the terms name an external verifier, for example an independent assay or inspection firm, the result is produced by that firm and entered by Wolf. Wolf records what the named verifier returned, together with the provider and the report reference, and does not originate the opinion. The control is available only on a condition whose verifier is external.

A PASS satisfies the condition and, with everything else in place, moves the transaction towards readiness.

A FAIL is a first-class outcome with its own control and its own confirmation, and the confirmation states both what it does and what it deliberately does not do. A FAIL fails the condition, blocks release and creates an operational review. It does not open a dispute. A dispute exists where a party contests the outcome or where the accepted terms prescribe one; an unfavourable inspection result on its own is a fact the parties now have to deal with, not a contested claim.

The distinction matters commercially because a dispute freezes funds and drags in the resolution machinery, whereas a failed condition leaves the money exactly where it was and hands the file to Operations for review. Conflating the two would put every failed laboratory result into dispute handling.

Where the terms make the Buyer’s confirmation a release condition, the product presents the exact question the terms ask, with no answer pre-selected and no shortcut that treats opening the screen as agreement. The Buyer’s Authorised Signatory answers it, and the answer is recorded against the condition with the identity and the time.

This is one of the places where the product deliberately does less than an automated system could. The reason is that a release on silence is a payment nobody authorised, and no deadline configuration makes that safe.

When a submitted document is formally wrong, the wrong revision, an unsigned copy, a missing annex, the answer is a correction request, not a dispute. The condition moves to Correction Required with the reason recorded, the party who submitted it uploads a replacement, and the replacement is approved. The transaction continues.

This is a defect path for evidence, and it exists precisely so that ordinary paperwork problems do not escalate. No dispute is opened, no funds are frozen and no resolution instrument is needed.

The version history is retained through the loop. The superseded document stays on the record marked as superseded, with its hash, its uploader and its time, and the replacement records which document it supersedes. Nothing is deleted, because a deleted revision removes the evidence of what was originally submitted and when.

Where the terms include one, Request Release is the Seller’s formal statement that it considers its side performed. It satisfies its own condition and nothing else. It triggers no payment, moves no money and does not on its own make the transaction ready for release.

The reason to keep it as an explicit condition rather than an informal message is that the moment the Seller claims performance is a contractual fact worth having in the record with a time and an identity, and because the Buyer’s confirmation and the external verifications frequently hang off it in sequence.

Repeating it changes nothing, and the control says so rather than silently recording a second event.

Funds are physically segregated per transaction. A fiat escrow is funded into a dedicated subaccount with its own IBAN, held with the payment partner, with a beneficiary, bank, BIC, IBAN, reference and required amount shown on the instruction. A digital-asset escrow is funded into a dedicated custody vault with its own deposit address, with the asset, network, address, vault identifier and the confirmations policy shown. There is no omnibus representation anywhere in the product, and no screen aggregates client money across transactions.

Funding instructions are issued only after both companies have accepted, and each instruction is valid for a specific terms version. When a new version supersedes the one an instruction was issued against, the instruction is marked as no longer valid rather than silently continuing to accept money against terms nobody accepted.

Every instruction carries a source ownership rule stating that the paying account or sending wallet must belong to the Buyer. Digital-asset instructions additionally warn that sending a different asset, or the right asset on a different network, is an exception that has to be investigated manually and that recovery is not guaranteed. Both warnings are on the instruction itself, where the person about to send the money is looking.

Every transaction carries an amount ladder rather than a balance: required, received, secured, released, refunded, remaining secured, and unallocated excess. They are different numbers and they are shown together, because the gap between received and secured is where most of the operational risk in an escrow lives.

Received means money arrived. Secured means it reached funding finality: reconciled against the requirement, compliance cleared, in the settlement currency, and with no blocking hold. A payment that has landed but has not been matched is received and not secured, and the Seller-facing copy never says the Seller is authorised to perform on the strength of it.

Funds Secured is all or nothing for a single-release transaction. Half of a required amount does not produce a half-secured state: it produces partially funded, with the outstanding gap named. The exceptions are deliberate and narrow. A milestone transaction secures milestone by milestone, because each milestone has its own requirement. Where the terms set a secured maximum for a variable amount, that maximum is the target, so a later increase in the certified final amount does not retroactively unsecure what was already secured.

Incoming money is matched on the reference, the account, the asset, the rail and the verified source of the payer. It is never matched on amount alone. Two transactions for the same figure between the same parties are ordinary in this business, and an amount match would eventually allocate money to the wrong escrow.

A funding event moves through detected, posted, pending review, information request required, reconciled, cleared, exception and returned. It carries the payer name, the payer ownership classification, the source account, the external reference, the credit time, the confirmation count where the rail has one, the KYT result, the Travel Rule status and an idempotency key. Reconciled and cleared are separate: reconciliation is the operational match, clearance is the compliance decision, and only cleared money counts as secured.

Partial and multiple funding is normal. Received is tracked against required with the gap and the top-up deadline named, and each credit is reconciled on its own rather than as an aggregate.

Three exceptions have their own handling. An unmatched payment stays in pending review and generates work rather than being force-allocated. A third-party payment, where the payer is not the Buyer, is a controlled manual exception and never a self-service path: the payer, its beneficial owner, the economic relationship, the reason for the payment, the source of funds and the sanctions result all have to be reviewed and approved before any of it can be secured, and a rejection does not automatically trigger a return where movement is prohibited. A wrong-network or wrong-asset deposit is an investigation, not a credit.

Where the required documentation is not yet complete, funds received are held and remain unsecured. The policy for how long and what happens next is an open dependency; holding them unsecured is the safe state the product uses in the meantime.

When more money arrives than the requirement calls for, the requirement is satisfied and the surplus is held as unallocated excess. It is never credited to a balance, never used to satisfy a later requirement automatically, and never quietly netted off a fee. Unallocated excess appears on the amount ladder as its own figure so that nobody reading the transaction mistakes it for headroom.

Returning it is a movement of client funds and is handled as one. It prepares a residual return instruction with an explicit destination, a maker and a separate approver, exactly like a payout, and it settles and reconciles through the same rail machinery. It is not an adjustment to a number on the funding record, and the original funding event is left intact so the history of what actually arrived is preserved.

The product keeps three currency fields separate and never collapses them: the transaction currency the deal is denominated in, the funding asset the Buyer actually sends, and the settlement currency the Seller is paid in. Where they differ, an FX conversion sits between funding and securing, and it must complete before anything counts as secured.

A quote carries the pair, the provider, whether it is indicative or executable, the gross amount, the rate, the spread, the fee, the net amount, the request time and the validity. Only an executable quote can be approved.

The operative quote is always the latest one. Quotes expire, and refreshing produces a new quote rather than extending an old one. Earlier quotes remain visible as superseded history without live controls.

Approval is deliberately narrow. It binds the exact pair, amount, quote reference, rate, spread, fees and validity window, and a refreshed quote does not carry a prior approval forward. The client is approving one conversion on stated terms, not granting a standing mandate. Execution is refused without a valid approved instruction, and the executed rate, execution time and partner reference are recorded when it completes.

A conversion can produce less than the requirement needs, because the rate moved, because fees were higher than the indicative quote suggested, or because the deposit was short to begin with. When that happens the transaction moves to Additional Funding Required for the exact difference, and the Buyer tops it up.

Wolf does not extend credit. There is no control anywhere in the product that bridges a shortfall, advances the difference or releases against an expected top-up. This is the same rule that governs a variable final amount above the secured maximum, and it is the reason the shortfall state exists at all rather than being smoothed over.

Once the top-up has arrived, been reconciled and been cleared, the transaction is secured and must read that way. The quote’s own state does not outrank the funding position: a quote that once recorded a shortfall no longer makes the transaction read as short after the shortfall has been closed.

Where a refund follows a conversion, the refund leg returns in the settlement currency to the verified source. The product does not silently convert back, because a second conversion is a second market risk the client did not agree to take.

Every funded tranche starts a non-extendable 60-day custody clock. The clock is per tranche, not per transaction, so a transaction funded in three instalments carries three clocks with three different deadlines, and a milestone transaction carries clocks attached to the milestones they funded.

The start trigger differs by rail and is recorded on the clock: for fiat it is the actual credit, for digital assets it is the moment the required confirmation count is reached. A deposit that has arrived but has not reached the policy confirmation count has not started its clock and is not final for funding purposes.

The clock is not paused by a hold and not paused by a dispute. This is the point that surprises people, and it is the reason the custody workspace exists as its own surface: the operational reasons that stop a transaction moving do not stop the calendar, so a file that is stuck for good reasons still runs out of time. That workspace lists every clock across the book, most urgent first, with the number of tranches under custody, the total held, the count inside the fifteen-day warning window and the count that has reached the limit.

Ready for Release is derived, never set. It is the conjunction of the release conditions evaluated over their logic groups, the amount being fully secured, no active hold, no open dispute and no custody clock past its limit. Where it is not ready, the product lists the blockers: the amount not yet secured, each unsatisfied condition in its exact wording, each active hold with the amount it blocks and what it blocks, each open dispute with the frozen amount, and any expired custody clock.

The release itself runs in separate stages that are displayed separately, because collapsing them is how people come to believe an approved payment is a paid one. An instruction is prepared, it goes to approval, it is approved, it is submitted to the rail, it settles, and it is reconciled. Approved is not paid. Submitted is not paid.

Preparation and approval are different seats. Wolf Operations prepares the instruction; an Authorised Approver approves it. The preparer cannot approve their own instruction: the engine refuses it and names the role that holds the right. A higher value or risk band requires a second approval on top, from the MLRO or a Director. The exact thresholds are an open dependency, so the second band exists in the model with its value left configurable rather than being hard-coded to an invented number.

An instruction cannot exceed the remaining secured amount. A rejection by the approver never alters the secured funds, it returns the instruction with a reason.

Stoppability is stated per rail and per stage rather than promised in general. Once an instruction passes its point of no return it cannot be frozen, and a settled instruction is explicitly not stoppable. The exact point for each rail is an open dependency with the partners.

A transaction completes when the partner reports finality and a matching ledger debit exists. Neither on its own is completion. A partner acknowledgement without a debit is a claim; a debit without partner finality is an unconfirmed movement.

When a payout is rejected by the receiving bank or fails on the rail, the transaction moves to Settlement Issue. This is a settlement problem, not a dispute: the commercial entitlement is unchanged, the funds return to the dedicated escrow structure and remain secured, and no freeze and no dispute machinery is triggered. A corrected instruction can then be prepared and approved through the same maker and checker path.

The payout destination is a contractual field, not an operational preference. Changing it requires verification of the new destination and an amendment to the terms, which means fresh acceptance by both companies. A failed payout is a common moment for somebody to ask for a quick change of account details, and it is exactly the moment when a quick change is most dangerous.

Each leg of an instruction records its direction, amount, exact destination label and detail, rail, status and partner reference, and its failure reason when it has one. Fee legs to Wolf are shown as legs like any other, not netted invisibly.

Some transactions are priced on a formula rather than a fixed figure: a unit price against a certified quantity, with a tolerance. The terms then set a secured maximum, which is what the Buyer funds, and a certified final amount is determined later and approved.

Where the final amount comes in below the secured maximum, the payout and the return of the residual are prepared as paired legs in one instruction and approved together. Both legs are approved at once so that no remainder is left behind in custody with nobody owning the decision to return it, and both must reconcile before the transaction is complete.

Where the final amount comes in above the secured maximum, the transaction moves to Additional Funding Required for the exact difference and release is blocked until the difference is secured. Wolf does not bridge the gap. The Seller can see precisely what is outstanding, and the Buyer tops up through the normal funding path.

The secured maximum is also what protects the already-secured position: a later increase in the final amount does not retroactively unsecure money that was already reconciled and cleared against the maximum.

A milestone transaction is not a single escrow with a progress bar. Each milestone has its own amount, its own required and received and secured figures, its own release conditions, its own funding deadline, its own custody clock and its own state. That is why the transaction-level funding state reads partially secured rather than secured while any milestone is still short: it is a truthful statement about the whole, and the precise position is on each milestone.

Milestones release independently. One milestone can be completed and reconciled while the next is secured and awaiting release and the third is not yet funded, and the conditions tab groups the conditions and the custody clocks under the milestone they belong to. A completed milestone is marked immutable and is not reopened by an amendment to the remaining ones.

A hold freezes movement without asserting anything about the commercial merits. There are two kinds and they are never conflated. A compliance hold comes from the compliance function and carries a reason that stays inside Wolf. An operational hold comes from Operations, for example after a failed external verification, and is labelled as neither compliance nor dispute.

A hold records its scope, transaction or milestone, the affected amount, a reason code, the restricted reason that is never shown to a client, the client-visible summary that is exactly what the client is allowed to see, the client’s required action where there is one, who opened it, in what role and when, and the list of what it blocks, typically release, refund and conversion of the secured amount.

The client-facing message is neutral. A client under a compliance hold sees that the transaction is under review and what, if anything, is needed from them. They do not see the reason code or the restricted note, and no screen leaks it through a filter, a count or a status chip.

Only a party may raise a dispute. Wolf administers the escrow and records outcomes; it does not decide who is right. That boundary is stated on the dispute surface and enforced by the capability model.

A dispute names its scope, transaction or milestone, its affected amount, a reason category, the party’s statement and its evidence. The affected amount freezes. The remainder of the transaction is unaffected, which matters on a milestone transaction where one delivery is contested and the others are not. Nothing moves on the frozen amount without a binding resolution.

Only four resolution authorities are recognised: a joint instruction from both parties, a signed settlement agreement, a court order, and an arbitral award. Nothing else resolves a dispute in this product.

A resolution is recorded as executable amounts, not as a sentence. If the instrument splits the money ninety to ten, the resolution carries those two figures, and the release tab can then prepare both legs from it. This was a genuine gap in an earlier build: a summary line looked like a resolution but could not be prepared, approved or settled, so the split could not actually be executed. A split settles as paired legs in one instruction, under one compliance clearance and one separate approver.

Recording the instrument is administration, not a decision on the merits, so it belongs to Operations rather than to a client signatory capability. A binding resolution is the authority for the movement it describes: the commercial conditions it settles are precisely what the parties could not agree on, so they no longer gate the payment, and an instruction executed under a signed instrument is not the automated action the custody limit blocks. Compliance holds and any still-open dispute continue to block regardless.

After finality, a party may record a complaint. It is recorded and it freezes nothing, and the confirmation says so.

Compliance is not a gate at onboarding, it runs through the whole transaction. Funding is screened as it arrives, with a KYT result and a Travel Rule status on each digital-asset credit, and money is not secured until it is cleared. Screening is repeated immediately before every release, which is the case the compliance hold scenario demonstrates: everything commercial passes and a pre-payout alert stops the payout with the funds still secured.

Lifecycle events re-screen. Publishing an amendment opens a re-screening case. A change of beneficial owner, a new wallet, a third-party payment, a refund and a custody escalation each have their own case kind, so the queue says what kind of work it is rather than showing an undifferentiated list.

A compliance case carries an owner, a priority, a due date, a state, a client-visible summary, an optional client-required action, and a restricted note that clients never see. Clearance can carry a validity date, because a clearance that is months old is not a clearance at the moment of payout.

An information request is issued to the client with controlled visibility and answered in the product. While it is open, funds stay received and pending and cannot become secured.

Expired or invalid identification of a party triggers re-verification, which blocks release, refund and any new instruction. The product does not guess an outcome when authority is lost during a live escrow; it stops movement and puts the question to Compliance.

The compliance work generated by escrow appears in AML Officer 3.0, the compliance workspace, reading the same transaction record rather than a copied queue, so an officer and an operations user are looking at one file.

Visibility is a property of the document, not of the screen it happens to appear on. A document is shared, buyer and Wolf, seller and Wolf, Wolf internal, or compliance restricted, and every seat respects that classification everywhere the document could surface, including counts, filters and evidence lists.

Each document carries its name, type, version, hash, uploader and uploading company, upload time, the condition or milestone it belongs to, its review state and, where it replaces an earlier revision, the document it supersedes.

Review states are pending, approved, correction required, rejected and superseded. A superseded revision is never deleted. The point of evidence is that somebody can later establish what was submitted, when, by whom and what was done with it, and a deletion destroys exactly that.

On the compliance side the same rule protects the restricted reason behind a hold or a case: the client sees the neutral summary and their required action, and never the restricted note.

Two subjects this page leans on are written up on their own. Which seat may do what, and what each seat is refused, is the roles section. How a flow knows a step has happened, what is seeded and what a production build would put behind these screens, is the model section.