Know whose instruction it was.
Connect the principal, the agent, the applicable authority and the service outcome. Make the history understandable to the people responsible for it.
A readable record of responsibility.
When software participates in a financial workflow, a record of the final result is not enough. A team may need to understand who requested the action, which agent prepared it and what authority applied at the time. Without that connection, investigating an unusual result can turn into a search across disconnected systems.
SUPA’s design direction is to keep that chain visible. The responsible principal remains the starting point, with agent identity, permission context and service state connected to the instruction. The purpose is practical accountability: a record that helps a business or institution explain what happened.
Remember the authority that applied then.
Permissions change as teams, suppliers and workflows evolve. Looking only at an agent’s current access may not explain an earlier action. A useful operational record needs the relevant authority at the time of the instruction, together with any review or exception that affected it.
This principle informs the integration design. It helps distinguish an authorised operation from a prepared request, and an execution attempt from a provider-confirmed outcome. The exact records available depend on the enabled service and interface, but the underlying aim is consistent: avoid losing the reason an action was permitted.
Visibility with an appropriate boundary.
Accountability does not require every participant to see every piece of customer information. The person reviewing a business task, the platform hosting an agent and the institution delivering a service may each need a different view.
Access should follow the purpose and the approved relationship. A shared instruction reference can help connect the journey while the underlying information remains available only through the relevant permissions and procedures. Transparency is useful when it clarifies responsibility without creating unnecessary exposure.
Make review a normal part of the workflow.
A clear record is valuable when an action succeeds and even more valuable when it does not. It can show where a task paused, what information was requested and which party needed to make a decision. The review process should help the team resume safely, not merely collect a log after the event.
If you are building agent-enabled operations, we will discuss the questions your users and operational teams need the record to answer. Those questions help define the appropriate scope, approval path and integration requirements before more consequential actions are introduced.
A reviewer can follow the chain, not guess it.
Suppose an operator wants to understand why an agent prepared an instruction for a particular supplier. A useful review starts with the original business request, follows the agent’s permitted scope and shows whether a person approved the next step.
The service outcome then completes the picture. An action awaiting review should not look completed; a provider response should not be confused with the agent’s own interpretation. Connecting these distinctions gives a team a more reliable starting point for investigation and reconciliation.
Good questions.
Clear answers.
Who remains responsible when an agent is involved?
The relevant business and service providers retain their responsibilities. An agent acts within delegated authority; it does not replace the accountable principal.
Does every participant see the entire record?
No. Visibility is intended to follow the authorised role, service purpose and applicable information requirements.
Can access be changed after onboarding?
Agent access needs a reviewable lifecycle, including withdrawal. The available mechanisms and effects are specified for the enabled integration.
A closer look.
Agent-enabled services are being introduced in stages. Access, permissions and financial capabilities are agreed during onboarding and depend on the service provider, jurisdiction and use case.
Where could we take you?
Tell us what you want to build, connect or make possible.