Decentralised News · Agentic Finance · Decision research
By Heath Muchena · Source review 2026-11-14 · Instrument version 1.0.0
What Matters
Automating value transfer does not make its information handoff disappear. For a defined South African CASP-to-CASP route, record the customer evidence, originator and beneficiary packets, counterpart review and transmission timing separately. DN’s worksheet exposes missing references and timing issues; it neither sends personal information nor authorizes a payment.
A payment agent can select an asset, assemble an instruction and call a transfer service. That makes the boundary between the payment and its supporting information easy to miss. A transaction can appear complete on a ledger while the institution’s required information flow remains unresolved.
This article follows one route: a South African ordering crypto asset service provider, or CASP, making a direct domestic transfer to another CASP for a customer in an existing business relationship. It uses Directive 9 and FIC’s PCC 61 to frame the information handoff. The local record is intentionally narrower than those instruments.
The proposed method distinguishes eight evidence areas and a timing classification. It uses nonpersonal aliases, so the public worksheet never needs the actual customer or wallet information. The resulting record is a preparation and review aid for the responsible team, not a message sent to another institution.
DN Evidence Block
Sources reviewed: 2026-11-14 · Evidence type: South African Government publication of Directive 9, the FIC listing and authored PCC 61 guidance dated 30 March 2026, plus FIC’s explanation of guidance types; reviewed 13 November UTC / 14 November Johannesburg.
Scope: One direct domestic CASP-to-CASP qualifying transfer in an existing business relationship, viewed from the ordering CASP. The legal sources cover additional roles and routes.
- Directive 9 is the legal direction; PCC 61 is implementation guidance.
- The article distinguishes customer evidence, beneficiary information, counterpart CASP review and agent authority.
- DN’s eight-area worksheet and three examples are an original method with synthetic inputs.
- Existing OFAC route-change, KYA and treasury articles were checked for overlap.
Not established by this work: No customer records, sanctions screening, CASP registration, wallet ownership, message service, live transfer or compliance programme was inspected.
Original DN instrument · version 1.0.0
DN Travel Rule Handoff Record
Prepare a nonpersonal evidence record for one direct domestic transfer from an SA ordering CASP to another SA CASP within an existing business relationship. Keep packet references, counterpart review and information timing separate from transaction approval.
Enter your assumptions or load a labelled example. Required blank numbers stay missing; unknown evidence remains unknown. Use nonpersonal labels only. This instrument makes no network requests and uses no persistent browser storage.
Use your own inputs
No current result. Complete inputs or load an illustrative example.
A narrow evidence worksheet, not a Travel Rule messaging service, customer-identification system, sanctions screen, statutory reporting service or legal assessment. It does not cover every route, once-off threshold case, unhosted-wallet transfer or intermediary obligation. The two legal sources have wider scope than the worksheet.
1. Identify the ordering CASP and the exact route
Directive 9 covers specified accountable institutions acting in ordering, intermediary or recipient roles. This article narrows the working example to a direct domestic transfer between two CASPs in an existing business relationship. [1]
Write an internal reference for the role assessment before selecting a vendor or message format. “The agent pays” describes software behavior; it does not identify the institution that originates the transfer, the customer on whose behalf it acts or the recipient service provider. A wallet label is also insufficient to establish that the endpoint belongs to the expected institution.
DN’s worksheet asks the reader to declare this narrow scope. An unknown route remains unknown. A cross-border, intermediary, unhosted-wallet or different relationship case is sent to a separate assessment; the tool does not call it exempt.
2. Keep the customer relationship separate from the agent identity
PCC 61 explains that business-relationship transfers have no positive-value exemption from Travel Rule information requirements. A small amount does not turn such a transfer into an anonymous machine payment. [2]
Keep the customer-due-diligence reference beside the automation authorization. They answer different questions: who the customer is, and what the software may do for that customer. An agent identity credential can support an access-control design, but it should not overwrite the customer record or the CASP’s assessment.
The selected scenario deliberately excludes the once-off transaction branch. Operators should resolve the actual relationship classification through their controls. This worksheet does not advise how to restructure a transfer to obtain different treatment.
3. Map the originator packet to the applicable requirements
Paragraph 4.2 distinguishes natural and legal persons and sets out originator identity, address and transfer/account information. Paragraph 4.3 links the originator information to customer due diligence. [1]
DN recommends retaining a packet-schema reference and the controlled record that supplies each applicable field. The public worksheet needs only that reference alias. Do not paste the originator’s name, identity number, address, account number or actual payload into it.
Test the mapping in a synthetic environment before relying on it. A successful JSON parse establishes syntax, while the review needs to know whether the correct information was selected for this originator and route. A model-generated replacement for a missing field should remain a missing-evidence problem.
4. Preserve the beneficiary information as its own packet
Paragraph 4.4 specifies beneficiary information, including the name and applicable ledger and account details. [1]
Keep the beneficiary record separate from the recipient CASP’s organizational identity. The first concerns the receiver of value; the second concerns the service provider handling it. A copied address or a familiar institution name does not resolve both.
DN’s proposed reconciliation record links the beneficiary packet to the intended transfer without publishing personal values. If the instruction changes before execution, preserve the earlier packet and the reason for the replacement. This is a practical audit design, not a new mandatory message format.
5. Review the counterpart before sharing the information
Paragraph 4.7 requires identification and due diligence of the counterpart CASP before the information is sent, addressing confidentiality and illicit-actor concerns, with continuing review requirements. [1]
Record the approved destination and the current counterpart-review reference. An agent finding a cheaper endpoint or a faster route should not silently reuse the evidence for a different recipient. The receiving service must be the one the organization assessed.
PCC 61 also discusses interoperability and the limits of blockchain analytics. Its guidance does not prescribe one required software product. [2]
A vendor’s “Travel Rule supported” claim therefore needs a bounded demonstration: the correct counterpart, applicable fields, supported asset and a controlled failure case. No product was tested for this article.
6. Treat information timing as part of the handoff
Paragraph 7 requires the information before or with the crypto transfer. Later transmission is not permitted; secure handling is also required. [1]
Do not collapse “packet prepared,” “message sent” and “recipient received the intended packet” into one green status. DN recommends separate operational events so a reviewer can explain a failed or delayed handoff. A transport acknowledgement is useful evidence of that transport event; its exact semantics still need to be known.
The worksheet uses a declared timing classification rather than inventing a grace period or comparing unverified clocks. A planned transfer with no message yet sent is an incomplete preparation record. A started transfer followed by later information is flagged for escalation, without pretending that the worksheet determines the required remedial action.
7. Reconcile the packet, the transfer and the exception
Use a stable internal reference to connect the intended instruction, information packet and crypto transfer. Retain separate statuses when one succeeds and another fails. The reference should be usable by the authorized reviewer without exposing customer information in a public report.
For a synthetic test, let the message service time out after accepting a packet. The payment service should be able to distinguish an unknown delivery state from a proven rejection or a known success. DN’s recommended test records what the system actually observed and whether the transaction-control process acted on that state.
PCC 61 emphasizes that using an external service does not transfer the institution’s responsibility for the control’s effectiveness. [2]
Keep the resolved exception as an additional record. Replacing an earlier failure with a clean final status would make the operational history harder to reconstruct.
8. Keep the review record useful without calling it clearance
The eight evidence areas below are DN’s organization of a narrowly defined handoff. They are not the FIC’s complete obligations, an AML score or an approval to execute. FIC distinguishes binding directions from its guidance products; the source type and exact provision should remain visible in an internal assessment. [3]
A complete set of reference aliases can still point to outdated, inadequate or contradictory evidence. Assign an accountable owner to the underlying assessment and route unresolved matters through the institution’s controls. Customer due diligence, targeted financial sanctions and reporting duties remain separate from counting documentation fields.
The practical improvement to test is whether the team can explain a handoff: which packet was used, which party received it, when it travelled relative to value, what failed and who resolved the exception. This article proposes that test; it reports no measured improvement or live compliance result.
Methodology, limitations and corrections
The method counts eight administrative evidence areas: route and role, customer due diligence, originator packet, beneficiary packet, counterpart review, secure channel, packet-to-transfer reconciliation and exception records. A recorded status requires a nonpersonal reference alias. A known issue and an unknown area remain different states. Neither is converted into a numerical probability or a finding of unlawful conduct.
The timing result is conditional on the reader declaring the worksheet’s exact route. Before or simultaneous transmission satisfies the entered timing condition only. A started transfer with later or unsent information produces a timing issue. Preparation with information not yet sent remains unresolved. Contradictory combinations, such as a planned transfer with already-late information, are rejected.
The legal source text and DN’s operational recommendations are kept separate. Actual applicability, adequate due diligence, secure processing, reporting and transaction disposition require the institution’s assessment. The export retains the declared state, every reference and the unresolved questions; its authorization and independent-compliance values remain null.
For corrections, identify the claim, source and date when contacting Decentralised News. A new record-creation timestamp does not refresh its underlying evidence.
Change log: version 1.0.0, 2026-11-14. Initial documentation review, original instrument and labelled examples.
Frequently asked questions
Does a small crypto payment escape the Travel Rule in this scenario?
The selected scenario is a transfer in an existing business relationship. PCC 61 explains that the information requirement applies regardless of amount. Once-off transaction distinctions require their own analysis and are outside this worksheet.
Does a verified AI-agent identity replace customer due diligence?
No substitution is made here. Agent authority, customer evidence and the institution receiving the information are different records. A credential identifying software does not supply every fact needed for the underlying customer and transfer.
Does the tool transmit the Travel Rule packet?
No. It records user-entered statuses and nonpersonal aliases locally. It does not contact a CASP, inspect a packet, send a message or initiate a crypto transfer.
Can the same worksheet approve an unhosted-wallet transfer?
No. An unhosted-wallet, intermediary or cross-border route requires a separately scoped assessment. Selecting another route does not establish an exemption from the legal instruments.
Primary sources
- Directive 9 — Government Gazette 51556, Notice 5543, 15 November 2024. Scope and roles; originator and beneficiary information; counterpart due diligence; secure and timely transmission. Paragraphs 2–4 and 7. Reviewed 2026-11-13.
- FIC PCC 61 — Implementation of the Travel Rule relating to crypto asset transfers. Published implementation guidance, including business relationships, immediate transmission, interoperability, monitoring and retained institution responsibility. Reviewed 2026-11-13.
- FIC — Compliance guidance. Distinction between directives, public compliance communications and guidance notes. Reviewed 2026-11-13.
Turn the finding into a decision
For an implementation review, start with a redacted route diagram, the actual message specification and the unresolved handoff. Use the source provisions to brief the responsible compliance and engineering reviewers, then test failures with synthetic records. DN’s route-change record addresses a separate control question: whether the proposed transaction still matches the state that was reviewed.
Related DN research
Disclosure: Analysis and instrument results are editorial. Where labelled affiliate links appear, DN may receive compensation when you sign up or buy through them. Commercial relationships do not determine findings. No tested integration or guaranteed outcome is implied.
