Why payment is only part of an exchange

A software agent can buy information or another agent’s work on behalf of a company. A successful payment answers whether value moved. It does not, by itself, answer whether the purchase was permitted, whether the right work arrived, or who should respond when something goes wrong.

Sinetti is an open protocol FNA is designing so agents that do not know each other could adopt shared rules for an exchange. The purpose is to make identity, agreed conditions, recourse and useful records part of the design from the outset. These pages explain that purpose. They do not describe an available service or a settled implementation.

An example to follow through the docs

Imagine a retailer’s research agent buying a weekly market-data file from a supplier’s agent for an internal report. The retailer has authorised a particular purchase. The supplier offers defined coverage, a delivery time and a permitted use of the data.

This is an illustrative business scenario, not a Sinetti transaction or test. It gives the questions below a concrete setting without assuming a particular payment platform.

Four questions the parties need to answer

Identity, escrow, recourse and reputation are the areas described in Kimmo Soramäki’s introduction to Sinetti. Here, escrow is considered as one possible way to connect payment to delivery, rather than the definition of Sinetti.

Shared rules across different systems

A buyer and supplier may use different agents, identity services and payment platforms. An account on one platform need not explain what its operator authorised, and a payment record need not contain the agreement it paid for.

The useful connection is the same exchange: the parties, the permission, the agreed work, the delivery and any subsequent response. Sinetti’s intended role concerns these trust questions across systems. These docs do not assume a particular currency, wallet, blockchain or payment provider, and do not claim compatibility with any of them.

Related protocols are listed in the Registry. Inclusion there is a reference link, not proof of integration or endorsement.

What remains undecided

Specific identity checks, enforceable permissions, delivery assessment, dispute rules and record-sharing arrangements need defined responsibilities and evidence before anyone can rely on them. Those choices are not settled by giving the overall idea a name.

These explanations are for readers evaluating the problem and proposed approach. They are not instructions for sending money, selecting an arbitrator or integrating a released protocol. Sinetti’s earlier technical prototypes do not establish that these functions are available together.

Identify the parties behind the software

In the market-data example, the two agents are tools used by a retailer and a supplier. The supplier needs to understand which organisation is buying, and the retailer needs to understand which organisation is offering the data.

An agent name, account or technical credential may identify a piece of software. That does not automatically identify the organisation responsible for the purchase or establish who can answer a complaint. The parties need an understandable connection between the agent and the person or company it represents.

Identity and authority answer different questions

Identity asks who is involved. Authority asks what one party has permitted the agent to do. Knowing that an agent belongs to the retailer does not show that it may buy any dataset, agree to any licence or disclose the retailer’s customer information.

A useful permission describes its scope: the task, permitted supplier or kind of supplier, spending limit, time period and any restrictions on use or onward delegation. These are examples of information a policy may need, not a prescribed Sinetti permission format.

The grant of permission also needs a recognisable source. A statement made by the agent about itself is different from evidence issued by someone entitled to authorise the purchase.

Apply the permission to this purchase

Suppose the retailer authorised a weekly market-data purchase for an internal report. A supplier’s offer includes an additional resale licence at a higher price. The agent should not treat access to a payment account as permission to accept those new terms.

The changed offer raises a new question for the retailer: does the existing authority cover this price and use, or is fresh approval needed? A responsible design makes that distinction visible before the agent commits to the exchange.

What another party would need to check

A counterparty should be able to distinguish the claimed organisation, the agent acting for it, the source of the permission and the proposed action. It also needs to know whether that permission is current and whether its limits have already been used.

Evidence can be incomplete or outdated. An earlier permission does not explain a later cancellation. Separate purchases can each appear within a limit while exceeding it together. A trustworthy arrangement must explain who checks these conditions and what happens when a check is unavailable.

This is a design requirement, not a claim that Sinetti currently supplies those checks.

Share enough without exposing everything

The supplier may need evidence that this purchase is authorised without needing the retailer’s entire procurement policy or unrelated purchases. The retailer may need to identify the supplier without obtaining personal details about its staff.

The questions are practical: which facts must be disclosed, to whom, for how long, and who may inspect them after a dispute? Keeping a public record of everything is not a substitute for deciding what needs to be shared.

Permission does not settle legal responsibility

A record of authority may help explain what was permitted. Whether an agreement binds a company, who bears a loss and which law applies require the actual relationship and applicable rules. A technical credential cannot decide those questions on its own.

Sinetti’s intended identity and authority approach needs these responsibilities to be explicit. Accepted evidence, cancellation, delegated permissions and the treatment of uncertain checks remain decisions to resolve.

Make the offer understandable to both parties

The retailer’s agent is buying a weekly market-data file, but that description leaves room for disagreement. Which regions and dates does it cover? What fields and units will the file contain? When must it arrive, and what use is the retailer permitted to make of it?

The parties need the same agreed description before the exchange begins. A changed offer, revised file or late delivery should be distinguishable from the original agreement, so a later reader can see what changed and who accepted it.

Choose criteria that match the work

Some requirements are straightforward to check: a file opens, required columns are present, dates are within the requested week, or delivery occurred before the agreed time. Others involve judgment: whether the information is accurate, complete enough or useful for the retailer’s research.

Passing a format check does not prove that the underlying data is correct. An agreed assessment should state what is being checked, who performs the check and which questions remain outside it. Otherwise a narrow technical result can be mistaken for a judgment about the whole service.

Preserve evidence that answers a question

Useful delivery evidence connects the item received to the agreed work. For the data purchase, that might include the accepted offer, the delivered file version, its stated coverage, the delivery time and the result of an agreed inspection.

A receipt can show that something was submitted. It need not show that the buyer received usable data. A record that a file has not changed can help identify it later, but cannot prove that its contents were accurate. Each piece of evidence should have a clear purpose and a clear limit.

The parties also need to know who retains the underlying material. A reference to a file is of little help if it later disappears or neither party can share it with a reviewer.

Where escrow could help

Escrow means holding value subject to agreed conditions instead of paying the supplier immediately. In this example, the parties might consider holding payment while the agreed delivery check takes place. Whether that is appropriate depends on the exchange, the cost and the responsibilities involved.

The hard questions are the conditions: who establishes delivery, what happens after a missed deadline, and what happens when the check is disputed? Holding value does not answer them. Direct payment, platform protections and other arrangements may be appropriate in other situations.

Sinetti’s design includes escrow as one trust instrument. These docs do not specify an escrow provider, custody arrangement, release rule or supported payment integration. Sinetti is not presented as the recipient of the parties’ funds.

Handle changed circumstances explicitly

If the supplier cannot deliver the requested region, it may offer a smaller file. That is a proposed change, not proof that the original promise was fulfilled. The retailer’s agent needs authority to accept it, and the parties need to know what happens to the original price and deadline.

If the connection fails, neither party should infer from silence alone that delivery or payment succeeded. The available records may leave an outcome uncertain. An agreed way to confirm, pause or request a response matters as much as the ordinary successful path.

Questions to settle before relying on a service

• What is the agreed work, and how are changes accepted?
• Which checks are mechanical and which require judgment?
• Who keeps the evidence, and who can inspect it?
• What happens when delivery, payment or a check is uncertain?
• Which payment protections apply, and who is responsible for them?

These questions explain the design work required. They do not form a ready-made Sinetti agreement or operating rulebook.

First establish what went wrong

The retailer may report that the market-data file never arrived, arrived late, omitted a region or contained inaccurate values. The supplier may believe it met the agreed terms. These are different problems; a generic “failed” label does not explain them.

The first useful step in understanding the disagreement is to connect it to the actual agreement, delivery and available evidence. A failed connection or missing confirmation can leave the outcome unknown rather than proving that one party broke the agreement.

A complaint, a decision and a remedy are different

A complaint records a party’s objection. A decision assesses the disagreement under a set of rules. A remedy is the resulting action, such as correction, replacement, cancellation or an allocation of loss where the applicable arrangement permits it.

Recording an objection does not appoint a reviewer, reverse a payment or establish that the complaint is justified. Likewise, an assessment is not useful recourse unless the parties understand what effect it can have and who can carry it out.

Know who can decide and under which rules

The parties need a way to identify the responsible responder, the rules for raising a problem, the material a reviewer may consider and any relevant time limits. They also need to understand costs, conflicts of interest and whether a decision can be challenged.

The reviewer could be a person, a platform or a process accepted by the parties. These docs do not select one or claim that Sinetti offers an arbitration service. Automating a check does not remove the need to define its authority and limits.

A disagreement about coverage

Suppose the file contains most of the requested regions but omits one. If the agreed offer listed that region, the offer and delivered file help explain the complaint. If the offer said only “regional market data,” the disagreement may expose an unclear agreement rather than a failed automatic check.

The supplier might propose a corrected file. Whether that response is adequate depends on the agreed purpose and timing: a correction after the retailer’s report was due may have a different value from an on-time delivery. The evidence informs the discussion; it does not choose the outcome by itself.

Keep the exchange and its response connected

A later reader should be able to distinguish what was promised, what each party says happened, what evidence was considered and what response followed. An unresolved complaint should remain distinguishable from a confirmed failure or an agreed correction.

Some evidence may be commercially sensitive or personal. A useful process needs controlled access and retention, not an assumption that every document should be public. A summary should make clear when the underlying evidence cannot be independently inspected.

Recourse is not a recovery guarantee

A meaningful route for a complaint improves accountability, but does not guarantee a refund, compensation or a willing and solvent counterparty. Legal rights and enforceability depend on the actual parties, agreement and jurisdiction.

Sinetti’s intended role is to make recourse part of the design of agent exchanges. Decision-makers, adopted rules, binding effects, remedies and responsibility for losses remain matters to establish before a service can be relied on.

History can inform the next exchange

Before buying the data file, the retailer may want to know whether the supplier has delivered comparable work before. A history of relevant exchanges could help identify questions to ask, such as whether deliveries were timely or recurring complaints were resolved.

The value lies in the record and its meaning, not simply the presence of a badge or a large number. A history of small, routine deliveries need not predict performance on a much larger or different task.

Separate a claim from what supports it

A rating is someone’s assessment. A payment record shows a transfer. A delivery record may show that an item was provided. A complaint and a resolution add further context. None is a complete account on its own.

Ask who made the statement, which exchange it refers to, what was actually checked and whether the supporting material is accessible. A claim connected to a real purchase may be better grounded than an anonymous endorsement, but that connection alone does not establish honesty, quality or independence.

Compare histories without hiding the differences

One supplier might have ten recent deliveries of the same kind of market-data file, including a complaint that was corrected before the buyer’s deadline. Another might have many favourable ratings for a different service but no visible delivery detail.

The first history is not automatically superior. It gives more relevant information about this task and a visible response to a problem. The second leaves different questions unanswered. Compressing both into a single score can conceal that distinction.

Many accounts do not mean many independent people

One operator can control several agents, or cooperating parties can generate flattering records for one another. Even genuine payments can be arranged to make a history appear stronger than it is. Counting accounts or transactions is therefore not the same as counting independent experiences.

A reputation approach needs to consider who can create records, how related parties are treated and what evidence could reveal manipulation. These are open design questions, not a claim that Sinetti has solved fabricated activity or collusion.

Allow for missing context and correction

A record may be incomplete, disputed or outdated. Readers need to know its source and scope, whether a complaint was answered and whether an error was corrected. The absence of a history means a lack of evidence, not proof that a new participant is unreliable.

Publishing records also creates obligations to the people and organisations described. Access, correction, retention and disclosure need clear rules, especially where information from one exchange is reused elsewhere.

Sinetti’s intended approach

The aim is for evidence of past exchanges and their outcomes to carry useful meaning into later decisions between agents. The important question is what a reader can justify from the record, rather than how an existing prototype calculates a score.

Accepted evidence, independence checks, correction rights and any scoring policy remain to be agreed. These docs do not offer a live reputation service, endorse a counterparty or promise that historical records prevent future losses.

Why the guide is unavailable

It described an unsettled technical prototype. It should not be used as a current specification or integration guide. These docs now explain Sinetti’s purpose and the questions its design needs to answer.

The earlier material is not included in these pages or their search results.

Continue with the relevant explanation

• Identity and authority: who acts for whom
• Agreeing an exchange and delivery
• Recourse and responsibility
• What past records can show

For the overall direction, read the Sinetti overview.