# Advisa

> Transaction modelling and prototyping. We take a transaction a company already runs with other parties and write the whole of it down: their side, and what they are assuming about everybody else's.

Site: https://advisa.tech/
Deliverables in full: https://advisa.tech/deliverables/
Contact: deyan@advisa.tech
Operator: Advisa EOOD, UIC 206448172, Sofia, Bulgaria
Updated: 2026-08-15

## What the service is

Transaction modelling and prototyping. The output is a digital twin of a
transaction the client already runs: who takes part, what each may authorise,
what must never be true, and what each party can and cannot see. It can then be
extended into a working demonstration on a ledger, on Canton, Corda, Stellar or
Algorand, running on testnet.

It applies wherever goods change custody before the money moves, someone else's
certificate decides whether a party may act, security sits in a building the
lender does not control, a release needs several organisations to agree with no
place where they agree, or what went wrong is reconstructed from email weeks
later.

## Where the value appears

A transaction is worth mapping when cash, loss or capacity turn on how it runs. The starting point is not a ledger or a new system. It is
wherever the transaction already costs more than it should: money sitting still
while parties wait for paperwork, the same checks done twice, exceptions that
turn into disputes, gaps that hold back credit or capacity, and money spent on
systems before anyone was sure what was needed.

The model lets a client run the same transaction twice. Change one condition,
run it again, and see where that lands on every other party. That is how they
find out which conditions the cost, the delay and the exposure turn on, rather
than which ones everyone assumes.

- Release cash sooner. Delays between a physical event and the evidence, approval, payment, release or credit decision that depends on it.
- Lower the cost of each transaction. Repeated document chasing, reconciliations, duplicate data entry, manual checks and exception handling.
- Avoid expensive failures. The points at which a wrong release, stale certificate, conflicting instruction, duplicate allocation or missed deadline can create a loss or dispute.
- Increase operating capacity. Constraints that stop the business handling more volume, counterparties, facilities or products with the people and systems it already has.

The first result is not a proposal. It is a view of what drives the cost and what
moves when one thing changes, with the working shown so a client can argue with
it. We do not promise savings before seeing the transaction; we give a
client the evidence to decide whether a change can pay for itself.

## Where control ends

Internal controls do not stop mattering when a transaction crosses into custody,
finance, insurance, regulation or a new counterparty. They become the basis on
which another organisation decides whether to release goods, advance funds,
insure risk, accept a declaration or continue the relationship.

Advisa maps the point where internal operating control becomes externally
relied-upon evidence: what the other party needs to know, which facts they can
rely on, who is authorised to provide them, and what must happen when they
change.

- Before a facility is renewed, extended or increased. The other party needs to rely on: Whether financed goods are identified, eligible, not subject to an undisclosed competing claim, and released only through the agreed control process. The model establishes: The relationship between custody, stock position, lender control, release authority, evidence currency and enforcement state.
- Before a due-diligence statement or regulated declaration is signed. The other party needs to rely on: Which facts are established by suppliers, inspectors, warehouses or other parties; what evidence supports them; and how later correction or supersession is handled. The model establishes: A source-to-declaration evidence chain, accountable roles, effective dates, dependency record and exception path.
- Before a new warehouse, custodian or counterparty joins. The other party needs to rely on: What authority, evidence, access, control risk and operational dependency the new participant introduces. The model establishes: A before-and-after control map: what changes, which permissions are new, which evidence is now relied upon, and what controls need adjustment.
- After a release, claim, discrepancy or control failure. The other party needs to rely on: Whether the same weakness exists elsewhere, who could have acted, what they knew at the time, and what control should now prevent recurrence. The model establishes: A replayable event, authority and evidence view that supports root-cause analysis and a targeted remediation plan.

Control ends at the boundary. Accountability does not.

## What the model asks

What, exactly, makes the next action permitted? In a working operation that answer is spread across
people, documents, inboxes, systems and contracts, and a model cannot work from
"usually" or "the team knows". Each of these sentences conceals questions that
have to be answered before the next action is permitted:

- "The right person approves" requires: Which role, under which mandate, up to what limit.
- "The goods are available" requires: Which parcel, in whose custody, confirmed by whom and when.
- "The certificate is valid" requires: Issued by whom, for what scope, superseded by what.
- "The bank is protected" requires: Over which goods, ahead of whose claim, released on whose instruction.
- "The warehouse releases against instruction" requires: Which instruction prevails, and what can block it.
- "We handle exceptions manually" requires: Who decides, what freezes, what puts it back.

Any system that acts on these has to answer the same questions first, and most
of the answers sit with somebody else. Software inside one company can be
written from that company's own rules. A transaction crossing several companies
cannot, because the conditions sit with parties who are not buying the
software.

## What has to be true before a transaction can be modelled

What has to exist before a transaction can be written down. A transaction does not have to be orderly
to be modelled; the valuable ones usually are not. Five things have to exist:

- A consequential subject. Identifiable goods, a shipment, a warehouse position, a payment, a right, an account, a claim or a case. Something a party can point at and mean the same thing by.
- More than one party who can affect it. Someone instructs, another verifies, another holds custody, another finances, insures, accepts or regulates.
- Actions that change a position. Release, delivery, inspection, acceptance, payment, substitution, allocation, claim or cancellation.
- Conditions the actions depend on. Authority, evidence, quantity, quality, time, location, a hold, a payment condition or a previous event. If every action is negotiated fresh, you have a negotiation rather than a transaction, and there is nothing to write down.
- A process that can be observed. Not perfectly documented. Reconstructible, through people, documents, systems, physical hand-offs and the exceptions everybody remembers.

## Mappable, and ledger-ready

A transaction can be written down long before it could be enforced. These are two different states and most
transactions are in the first.

- Mappable when: You can reconstruct what happens, and why. Ledger-ready when: The parties can agree what counts as a valid state change
- Mappable when: You can identify the subjects, roles, evidence and hand-offs. Ledger-ready when: Each material action can be attributed to an authorised party
- Mappable when: You can expose the gaps and the ambiguity. Ledger-ready when: The necessary evidence can be issued, versioned, shared and relied upon
- Mappable when: You can state the controls you want. Ledger-ready when: Those controls can be checked before the action is accepted
- Mappable when: You can describe the exceptions. Ledger-ready when: There is an agreed response when physical reality, evidence and instructions conflict

This is why the model comes first. A ledger cannot resolve an unclear transaction. It can only make an unclear process run faster, and permanently.

## Where this usually applies

- Goods change custody before the money moves: Working capital, and credit exposure you cannot size
- Someone else’s certificate decides whether you may act: Waiting time, and acts taken on evidence that has since changed
- Your security sits in a building you do not control: Collateral uncertainty, advance rates, facility capacity
- A release needs three organisations to agree, and there is no place where they agree: Approval delay, duplicated checking, disputes
- What went wrong is reconstructed from email, weeks later: Claims and recoveries that arrive too late, audit preparation as a project
- Getting it wrong has a meaningful downside: Trapped cash, unsecured finance, duplicate allocation, uninsured movement, rejected cargo, dispute
- Somebody outside already has a reason to want it fixed: A lender, an insurer, a regulator, a new counterparty or a systems programme that is waiting on you

## Why it matters

In a transaction that crosses several organisations, no single party sees the
whole sequence, and decisions worth real money get taken from half a picture.
We do not digitise the commodity. We model the control around it: who
may act, under what authority, on what evidence, and what must never happen. A client can then test a change on the replica
instead of on a live cargo.

## The problem it addresses

Six parties. From any position you can see three of them. In a transaction with several parties, each keeps a complete
record of its own part and none of them holds the transaction. When something is
questioned the argument is not about the facts, it is about whose file is
authoritative.

## What gets written down

Every transaction is made of the same classes. Where the weight falls is what
makes one trade different from another. Six of them carry most of the load:

- Subject: The thing itself. Which parcel, which batch, which cargo, identified so two parties cannot mean different things by it.
- Interest: Who has a claim on it, and whose claim comes first.
- Fact: What is asserted to be true, by whom, and from when.
- Obligation: What someone owes, to whom, and by when.
- Invariant: What must never be true, whatever else happens.
- Disclosure: Who may see what, and who may not.

There are more. Which of the others matter is settled against a real
transaction, not in advance.

Where the weight falls, by trade:

- Softs and agri. Leans on: Fact, Invariant. Turns on: Whether the figure that governs is the one everyone is acting on
- Metals under finance. Leans on: Subject, Interest. Turns on: Whether anyone else has a claim on the same goods
- Energy in transit. Leans on: Obligation, Fact. Turns on: Whether “released” means the same thing to the carrier, the terminal and the bank
- Chemicals in distribution. Leans on: Disclosure, Obligation. Turns on: Which declared fact binds, and who it binds downstream

Two parties to the same transaction fill in the same list differently. Where
they differ is what we are looking for.

## How an engagement runs

Three stages, priced as one scope and invoiced by stage. Each stage takes four
weeks and ends in a review, and a client can stop with a complete, useful
deliverable after any of them. The fee for each is fixed before it starts and is
not revised afterwards. The first two need no ledger and produce no code.

A ledger is a test instrument before it is a system. "The right person
approves." "The certificate must be current." "The goods cannot be released while
finance is outstanding." A ledger will not run on an approximation. Every rule of
that kind has to become exact, or nothing happens. Stage three does not deploy
the model. It puts the model
somewhere that cannot quietly fill a gap with interpretation, and sees what
breaks. A ledger is not a requirement; enforceable control is.

1. Map the transaction. Map parties, hand-offs, documents, physical events, delays and exceptions. You leave with: Six documents, including the transaction map, what each party can and cannot see, and who may act on whose say-so.

2. Define authority and control. Identify who may approve what, what evidence is required, what must never occur, and how exceptions are resolved. You leave with: Seven documents, including the state and control specification, the authority and evidence policy, and what each route forward would require.

3. Prove the control design. If the business case supports it, turn the agreed control model into a working prototype on a test ledger, where each party sees only its own side of it and you can still see the whole. You leave with: Eight documents and the repository, including the working transaction, the scenario suite, the control-evidence log and the build-or-stop analysis.

## What a client actually receives

The six deliverables, and what you can do with each
- Transaction map. Shows the real end-to-end sequence: parties, systems, documents, physical events, decisions and hand-offs. It becomes a common reference for operations, finance, legal and technology.
- Participant-view matrix. Shows what each party sees, needs, controls and cannot see. This exposes where teams are waiting on incomplete information or making decisions from assumptions.
- Who acts, and on whose say-so. Identifies who can instruct, approve, release, block, override or merely observe each material action. This is often the most immediately useful risk and governance output.
- Evidence and dependency register. Lists the facts that matter, the evidence that supports them, who issues it, who relies on it, how long it remains valid, and which external systems or documents feed the process.
- Bad-day playbook. Maps at least the normal path and two credible failure paths: late evidence, conflicting instruction, quantity mismatch, failed payment, expired mandate, lost custody control, dispute. This is where hidden weaknesses become visible.
- Value and issue register. A ranked list of delays, duplicated work, trapped cash, loss exposure, capacity constraints and avoidable technology spend, with an initial hypothesis of what each is costing or preventing.

The seven deliverables
- State, action and control specification. Defines permitted states, actions, preconditions, deadlines, finality and the rules that must never be broken. This is the spine for any workflow, integration or smart contract.
- Authority and evidence policy. The approval, delegation, evidence, reliance, disclosure and exception rules in a form that operations, risk and legal can review.
- Exception, dispute and enforcement design. What happens when the normal path fails: who decides, what is frozen, which notice is required, how reconciliation works, and how a case reaches resolution.
- Where the model and the operation diverge. The points at which the model does not yet describe how the transaction is actually run: a role it assumes that nobody holds, a field no system can produce, a step that rests on one person being available, a term you could not ask a counterparty for. Each set out with what the model would have to account for, so the distance between the two is explicit now rather than discovered during an implementation.
- Business case and success measures. For each change you are considering: the intended benefit, the assumptions behind it, where it starts from, who would own it, and which of the agreed numbers would move if it worked.
- What each change would need. The changes you named, sorted by what they depend on: those you could make with the systems you already have, those needing a process or policy decision, and those that would need technology investment or a prototype. Sorting rather than ranking; the order is yours to set.
- What each implementation route would require. Four routes side by side: no new technology, improving the existing workflow, integrating systems, or building a controlled prototype. For each, what it would take, what it would not solve, what it depends on, and what would make the case for it fail. The choice is yours.

The eight deliverables
- Multi-party working transaction. The agreed normal transaction run across separate participant views: instruction, evidence, approval, state change, release, payment or settlement marker. It turns a paper design into something your team can challenge.
- Role-specific sandbox. Operations, finance, risk, legal and technology can enter the transaction from their own position. This reveals whether the design works for the people who must use it, rather than only for its authors.
- Critical-scenario suite. The normal path plus the few failures that matter: stale evidence, conflicting instruction, delayed payment, expired mandate, quantity mismatch, loss event, default or disputed claim. This proves what becomes blocked, who is notified and who can resolve it.
- Control-evidence log. A readable record of every material act: who acted, under which authority, which evidence was used, what state changed and which control was checked. It lets risk, audit and legal assess the design without reading code.
- Reconciliation and finality demonstration. Shows whether the record can be reconstructed from events, how it relates to source systems, and the difference between requested, acknowledged, legally effective and physically irreversible actions.
- Architecture fit assessment. Explains why that particular environment was chosen for this transaction: privacy, participant control, event history, finality, interoperability, cost and operational ownership. It is not a generic blockchain comparison.
- Production-readiness gap register. A precise list of what remains before a live implementation: legal agreements, integration work, identity and access model, data ownership, evidence controls, security review, governance, operating procedures and support.
- Build-or-stop analysis. What proceeding, redesigning selected controls, running a limited pilot or stopping would each require, set against what the prototype proved. It states the evidence, the dependencies, the case for and against each, and the next sensible spend. The investment decision is yours.

The stage three prototype is not production software and does not replace a
client's legal agreements, systems or operating controls. It is a decision tool:
a working proof of what can be enforced, and what still depends on people or on
external evidence.

## Research behind it

Argent is a working system for metal held in a warehouse and pledged against a
loan. The goods stay where they are and the owner stays the owner. What gets
recorded is who has claimed what, who approved it, and against which document.
The same thing was then built three more times, on three other platforms, to find
out what each one could and could not handle: twenty-three actions, eleven rules
that must never be broken, and one test, which is to rebuild the whole history
from the records alone and check that it matches.

- Argent on Stellar, Soroban
- Aurum on Canton
- Ferrum on Corda
- Stannum on Algorand

## Author

Deyan Paroushev, Advisa EOOD, Sofia, Bulgaria. UIC 206448172.
deyan@advisa.tech · https://github.com/deyan-paroushev