Bank compliance teams should use Hong Kong's new Project SAGE to examine how responsibility and evidence pass between participants in an agentic financial transaction. A useful starting point is a disputed payment: who can reconstruct the customer's instruction, the agent's authority, the bank's checks and the eventual result?
The Hong Kong Monetary Authority launched Project SAGE on November 2. Its work spans use-case exploration, agent identity and delegated authority, interoperability, and legal and regulatory considerations including liability and consumer protection. The regulator also established a cross-sectoral expert group. A separate announcement confirms a discussion paper seeking industry feedback on banks' use of agentic AI. These are exploratory and consultative steps. They do not, by themselves, establish a new binding transaction rule or certify a participating service.
Start with the customer question
Consider an illustrative procurement assistant that receives a request to buy a replacement component. It selects a supplier, presents an order and initiates a payment through a financial provider. Later, the customer disputes the amount or destination. This example is Maetra's analysis, not a reported Project SAGE deployment.
Each participant may have a plausible local record. The assistant retained the conversation. The supplier retained an order. The bank retained a payment instruction. Yet those records may describe different versions of the transaction. An assurance review needs to establish which evidence connects them, and where that connection ends.
The most useful question is concrete: can another reviewer follow the customer's intended purchase through to the financial effect without assuming that every system interpreted the instruction identically?
Define what each handoff must preserve
Maetra recommends documenting a small evidence agreement before expanding a pilot across organizations. It should identify the information passed at each boundary, its owner, the retention basis and the procedure for resolving an inconsistent record.
| Boundary | Evidence to examine | Question it should answer |
|---|---|---|
| Customer to agent | Instruction version and permitted scope | What outcome did the customer request? |
| Agent to service | Agent identity, delegation reference and exact request | On whose behalf was this request made? |
| Service to payment provider | Transaction reference and applicable checks | What financial action reached the provider? |
| Execution to support team | Outcome, exceptions and linked records | What happened, and what remains unresolved? |
This is a suggested review structure, not an HKMA checklist. A shared identifier helps find related records, but its presence does not prove that the underlying instructions, permissions or amounts match. Review the values and their versions as well.
Keep identity, permission and outcome distinct
A verified agent identity can help establish which system made a request. It cannot alone establish that the customer intended that purchase or that the resulting payment was correct. The review should separately examine identity, delegated scope, service authorization and the observed result.
For the illustrative procurement flow, test a changed beneficiary after the customer approved an order. Determine whether the changed request is rejected, returned for review or accepted under an explicit rule. Record the actual behavior and the responsible endpoint. Do not infer downstream enforcement from an upstream permission screen.
Also test an expired delegation and an interrupted response. A timeout can leave the caller uncertain even when another system accepted the transaction. The support procedure needs an authoritative reconciliation step before anyone repeats the action.
Make disagreement a test case
A pilot that only demonstrates successful payments leaves the difficult accountability questions unanswered. Give the participating teams a deliberately inconsistent test record and ask them to reconstruct the sequence.
For example, the agent's record could show one amount while the provider's accepted instruction shows another. Establish which team investigates, how the customer can raise the issue and what evidence the team can access. Preserve only the data necessary for that purpose, with appropriate access controls. Broad copying of customer conversations into every participant's logs creates its own exposure.
The result should identify missing evidence and unresolved responsibility. It should not assign legal liability by inference. Liability, applicable duties and customer remedies require the relevant contracts, law and professional assessment.
Turn the initiative into a scoped review
Independent coverage by RegMemo discusses the initiative and consultation. That corroborates the public policy development; it does not establish that any proposed control has been implemented or tested by a bank.
For a compliance owner, the next useful artifact is a single transaction review with named evidence owners, an unresolved-issues register and a trigger for revisiting the assessment when the service or supervisory position changes. Maetra's Comply supports framework mapping, regulatory watch and evidence management. Those capabilities can support the review process without determining legal responsibility or guaranteeing compliance.
Use Maetra's framework coverage to connect the applicable requirements to current evidence for one bounded agentic-finance workflow. Keep proposed practices, demonstrated controls and unresolved questions visibly separate.