Transaction modelling and prototyping.
If you need to:
- renew or increase a facility;
- persuade a lender to finance a new flow;
- onboard a warehouse, custodian or buyer;
- make a high-value release safer;
- resolve a recurring discrepancy without slowing every shipment;
- show a prospective counterparty that you can operate to the standard it requires.
This is what we do. The model is written once and reused: a new facility, a new counterparty, a new warehouse, a changed evidence requirement.
Before a lender extends a facility against goods, it needs to understand what can be released, on whose authority and against which current evidence. We map that control around one transaction you already run, identify where the process cannot support the reliance being asked of it, and give you a practical basis for the facility discussion.
For most companies moving physical goods, the hard part is not buying and selling. It is getting six, seven or eight separate organisations to act in the right order, each working from its own records, while money and risk change hands before anyone can see the whole picture. Buyer, seller, warehouse, inspector, bank, insurer, carrier, regulator.
Done properly, that description is a digital replica of the transaction: one shared model that operations, finance, legal and technology can all work from.
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. The aim is not to make transactions more technical. It is to make them more controllable.
It is not useful when the difficulty is inside one company, when there is no decision waiting on the answer, or when the parties will not describe how the transaction really runs, workarounds included. In those cases we will say so.
When your control must be trusted by someone else.
Your 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.
Four moments when somebody outside has to decide whether to rely on it
| When it gets asked | What the external party needs to rely on | What the transaction model establishes |
|---|---|---|
| Before a facility is renewed, extended or increased | Whether financed goods are identified, eligible, not subject to an undisclosed competing claim, and released only through the agreed control process. | 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 | Which facts are established by suppliers, inspectors, warehouses or other parties; what evidence supports them; and how later correction or supersession is handled. | A source-to-declaration evidence chain, accountable roles, effective dates, dependency record and exception path. |
| Before a new warehouse, custodian or counterparty joins | What authority, evidence, access, control risk and operational dependency the new participant introduces. | 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 | Whether the same weakness exists elsewhere, who could have acted, what they knew at the time, and what control should now prevent recurrence. | 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.
When a fact changes, but the transaction does not.
One correction. Six parties. Nobody sees the whole consequence.
These are three physical transactions: coffee, gasoil and copper concentrate. The goods differ and the control problem does not. A quantity changes after the certificate has been issued, the inspector or the surveyor knows, and everybody else is still deciding from the earlier figure.
Nobody is lying and no single record is wrong. Information does move between these parties. What is missing is a common, current record that governs the next act, and that is what the Shared row in each card counts.
The first card is what each party holds. The second is what each was working from on the Wednesday. The third is where the consequence landed by the Friday, and on whom.
The point is not that every party should see every document. It is that a fact which changes an important decision should reach the people entitled to act on it, before goods are released, finance is advanced, cover is declared or a claim becomes hard to settle.
Switch the trade to see the same three cards in gasoil and in copper concentrate. The parties change name and the failure does not.
- Seller
- Instruction, invoice
- Buyer
- Contract, acceptance
- Inspector
- Quantity report
- Warehouse
- In, out, release
- Bank
- Advance, security interest
- Insurer
- Declared value, cover terms
- Shared
- nothing
- Sequence
- reconstructed → by email
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 you run the same transaction twice. Change one condition, run it again, and see where that lands on every other party. That is how you find out which conditions the cost, the delay and the exposure turn on, not the ones everyone assumes.
A transaction does not have to be orderly for this to work. The valuable ones usually are not, and a process nobody has written down is the normal starting point, not an obstacle.
Four places the money usually sits
| Value created | What we look for |
|---|---|
| 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. |
Where this applies, and what it is costing
| When this is true of your transaction | What leaks |
|---|---|
| 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 |
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 you can argue with it.
Start with the clarity you need. Continue only when the case is proven.
Software inside one company can be written from that company’s own rules, because the company has them. A transaction crossing several companies cannot, because the conditions sit with parties who are not buying the software. The first two stages are not preparation for a build. They are what a build would have to be written from.
| Stage | What happens | What you leave with |
|---|---|---|
| 1. The transaction control model | Map parties, hand-offs, documents, physical events, delays and exceptions. | 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. | 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. | Eight documents and the repository, including the working transaction, the scenario suite, the control-evidence log and the build-or-stop analysis. |
What you leave with at each stage, what gets measured, and what a prototype is built to answer →
What you hold after each stage, what it lets you do, and what each stage does not reach →
Each stage takes four weeks and ends in a review. You can stop with a complete, useful deliverable after any stage. The fee for each is fixed before it starts and is not revised afterwards. The first two need no ledger and produce no code. If nothing needs changing, you have a description of how it works that did not exist before, and the fee is the same.
A transaction can become an asset the company learns from.
Most companies only see a transaction while something goes wrong: a delayed document, a disputed release, a changed certificate, a financing condition that cannot be met.
A high-value transaction produces useful signals all the time. It shows where information arrives late, where two parties rely on different versions of the same fact, where checks are repeated, and where a new counterparty would need more confidence before joining. The question is whether the company can hear those signals, and do something with them.
Transaction mapping describes what happens. Transaction control decides what may happen. Transaction intelligence lets the transaction detect, communicate and improve what happens.
A transaction does not need artificial intelligence to teach a company something. It needs to retain the signals, decisions and exceptions that the company currently loses.
What a transaction should do, and what that means in practice
| A transaction should | In practical terms |
|---|---|
| Listen | Receive the events and evidence that matter: updated weights, a delayed payment, a release request, a revised inspection, a new claim. |
| Understand | Hold what the event changes: eligibility, authority, exposure, delivery, insurance, payment or a facility. |
| Tell | Inform the right party, at the right moment, with only the information they are entitled to see. |
| Remember | Retain what happened, who relied on it, what failed, what was overridden, and what the outcome was. |
| Learn | Show the recurring causes of delay, loss, disputes and duplicated checks, so the process can be redesigned against something other than opinion. |
| Connect | Give a new bank, warehouse, insurer, customer or supplier a clear way into the transaction instead of six weeks of finding out how it works. |
The questions a company starts asking
- Where did the transaction wait, and why?
- Which evidence arrived too late, or was used after it had changed?
- Which party was asked to rely on something it could not verify?
- Which exception recurs often enough to be worth redesigning?
- Which requirement makes a new lender, insurer or counterparty hesitate?
- What would have to be explicit for this transaction to be reusable elsewhere?
The model promises no platform. It gives you the control design from which a transaction can become more visible, more adaptable and more credible to the parties it depends on.
We help you turn an important transaction into something that can be understood, improved and trusted by the parties it depends on.
A well-designed transaction does more than move goods and money. It listens for what has changed, tells each party what they need to know, preserves what was relied on, and becomes easier to finance, operate and extend.
A transaction learns only when its parties design it to.
A transaction becomes more useful over time when the parties decide, explicitly, what it should notice, what each change means, and what must happen next.
This does not require every party to share everything. It requires each party to contribute the facts it is responsible for, receive the information it is entitled to use, and know the conditions under which it may act.
If the assayer issues a revised dry-weight certificate, the transaction does not think. It applies an agreed rule: this changes the financeable quantity, stops release above the revised amount, tells the bank and the warehouse what they need to know, and preserves the earlier certificate together with who relied on it.
Seven design choices, and what each is worth
| Design choice | In practice | What it is worth |
|---|---|---|
| Give the transaction a subject | Identify the cargo, batch, facility, invoice, entitlement or claim precisely enough that parties cannot mean different things by the same word. | Fewer disputes, duplicate records and wrong releases. |
| Give it senses | Define the events and evidence that matter: inspection, custody movement, payment, approval, expiry, amendment, claim or exception. | Important changes are less likely to be missed or discovered late. |
| Give those signals meaning | Agree what each event changes: eligibility, authority, value, exposure, delivery status, insurance or payment. | Decisions become consistent and explainable, instead of depending on who happens to remember what. |
| Give it a voice | Define who must be informed, what they are allowed to see, and whether an event permits, requires or blocks an action. | Less chasing, faster decisions, and clearer accountability across organisations. |
| Give it memory | Keep the evidence, decision, version, reliance and override together in a usable history. | Faster resolution of disputes, audits, renewals and financing discussions. |
| Give it feedback | Review the recurring delays, exceptions, overrides and losses the transaction produces. | Process improvements are based on operating evidence, not opinion. |
| Give it an interface | Define what a new bank, warehouse, insurer, customer or supplier must provide and what it can rely on. | Faster onboarding, and a transaction that is easier to extend to new counterparties. |
The result is not one organisation controlling everybody else. It is a transaction in which each party can contribute responsibly, act with clearer authority, and rely on a more dependable process.
That can improve operations, reduce avoidable exposure, support stronger financing conversations and make the company easier to do business with.
How the six become one register, and which stage produces each
We design the conditions under which a transaction can reveal what it needs, respond consistently to change, and become easier to improve over time.
One person, from the first conversation to the last document.
Advisa is led and delivered by Deyan Paroushev. He leads every engagement from the first conversation through to the final recommendation: transaction model, written material and, where appropriate, working prototype. The person you speak with is the person responsible for the work.
A transaction model is built out of detail: a document version, a release condition, an exception normally settled by a phone call, the difference between custody and ownership. Keeping the work with one person is what keeps that context intact. Continuity does not make the work better by itself. It makes responsibility unambiguous.
The method came out of a doctoral thesis on modelling smart contracts at Sofia University. The four implementations behind What a record holds were the experiment that tested it against four architectures. Before that, twenty years working with large organisations across Europe and Australia, on the other side of the table from the people who will read these documents.
Advisa EOOD is registered in Sofia. The work happens where the transaction does.
Which transaction would you least like to be asked to reconstruct?
Tell us which one, and which organisations take part. We will write back with what we think it turns on and what we would need to see to be sure, so you can decide whether a conversation would be useful. You will see every question we would ask before you commit to anything.