Payment operations · EMIs & PSPs
Zygos moves payment instructions through one state machine — validated, approved under four eyes that cannot be walked around, submitted with a key that makes a retry harmless, and written to a trail that cannot drift.
You hold the funds and the licence. Zygos is the software you run them on.
The reality
The approval queue blocks the person who created the instruction — so an operator edits a colleague’s draft instead, then approves it. That is self-approval with an extra step, and the control reports itself as green the whole time.
A submission times out. Nobody knows whether it landed. Someone retries, and the counterparty is paid twice — then it is a reconciliation problem, a clawback problem and a conduct problem, in that order.
The trail is reconstructed from application logs and inference at the point someone asks. It does not describe what happened; it describes what could be pieced together later.
The control path
Every instruction walks the same path, and there is no other way to move one. That is what makes the audit trail a description of reality instead of a report about it.
failed · returned — a branch is still a recorded transition, never a silent one
Maker-checker sits between validated and approved. The maker cannot be the checker — and neither can anyone who materially edited the instruction.
Minted at submitted and carried to the provider. It is the single control that stops a retry paying someone twice.
Every transition writes an audit entry. Entries are never updated and never deleted — the trail only grows, so it cannot be tidied up afterwards.
The difference
None of these can be added to a live payments system later without redoing the write path — and nobody ever gets budget for that. So they are in from the start.
The approver must not be anyone who created or materially edited the instruction. Every actor who contributed is disqualified from signing it, permanently — so edit-then-approve is closed, and so is edit, revert, then approve. Revert the rule to the usual approver ≠ creator and four tests fail.
Append-only, and a consequence of the design rather than a feature on top of it. Every transition writes an entry, and there is no other way to move an instruction — so the trail cannot disagree with reality. Instructions snapshot their counterparty too: editing a party later never rewrites what was approved.
The key is minted once at submission and carried to the provider unchanged on every retry. Enforced in the write path, not added later, because it cannot be retrofitted into a live payments system. Mutation-tested on real Postgres rather than an in-memory stand-in: remove the guard and 31 tests fail.
One connector never validates an abstraction. The port is designed against a REST/JSON cashier API and ISO 20022 XML — maximally different on purpose. Both run as faithful mocks of the published contracts today, so the port is proven and the live integrations are not. A new provider is a package; never a fork of the core.
Walkthrough
Every payment instruction walks one state machine. These are the two points on it where a control has to hold on its own — with no operator remembering to be careful. Pick one.
Most four-eyes checks only block the creator. Zygos disqualifies every actor who touched the instruction, so editing a colleague’s draft is not a way in.
The retry is not rejected and it is not a second payment — it returns what the first submission did. That is what exactly-once means at the connector boundary.
Illustrative sample data — a walkthrough of the modelled state machine, not a live connection to a payment provider.
Questions
Including the two we would rather you ask now than at the end of a technical evaluation.
No, to both. Zygos is a technology provider, not a licensed entity. You hold the funds and you hold the licence; Zygos is software you run to operate them. Regulation attaches to holding client money and executing payment transactions — not to the back-office software that helps a licensed firm do it. We do not touch client money, and we will never tell you we are an EMI, an agent or a payment institution, because we are none of those things.
It means real obligations, and we would rather price them in than pretend they do not exist. Once you run critical operations on our software, the EBA outsourcing guidelines and DORA reach us through your contract: audit rights, exit plans, incident reporting, subcontractor disclosure, and RTO/RPO commitments. That is contract and process work we expect to do with you, and we would rather scope it with you early than have it surface in a questionnaire late.
An idempotency key minted once at submission and carried through to the provider unchanged on every retry. A retried submission returns the original payment rather than creating a second one — the retry cannot pay twice. It is enforced in the write path, not added as a later hardening pass, because exactly-once submission is not something you can retrofit into a live payments system. It is also mutation-tested against real Postgres rather than an in-memory stand-in: remove the guard and 31 tests fail. A test suite that stays green with the control removed proves nothing, so we check that ours does not.
The approver must not be anyone who created or materially edited the instruction — not just the person who created it. That closes the loophole in most four-eyes implementations, where you can edit a colleague draft and then approve it yourself, which is self-approval with an extra step. Zygos records every actor who contributed to an instruction and disqualifies all of them from approving it, server-side. Contribution is permanent, so editing and then reverting does not buy the approval right back; a no-op edit does not cost it, because a reviewer who saves an unchanged draft should not silently lose it. The rule is mutation-tested: revert it to the usual approver-is-not-the-creator check and four tests fail.
The audit trail is append-only and it is a consequence of the design rather than a feature bolted onto it. Every state transition writes an entry, and there is no other way to move an instruction — so the trail cannot drift out of step with what actually happened. Entries are never updated and never deleted; the trail only grows. Instructions also snapshot the counterparty details they were raised against, so editing a party record later cannot retroactively rewrite what was approved.
Zygos is provider-agnostic by construction. A connector is a package implementing a fixed port — submit, get status, fetch statement — so a new provider is a new package, never a fork of the core. Two deliberately different shapes are built against their published contracts: a REST/JSON cashier API (Praxis) and ISO 20022 XML (pain.001, pain.002, camt.053). Both currently run as faithful mocks of those published contracts, not as live connections; moving one to live is a base URL and credentials change rather than a rewrite, but that work is ahead of us, not behind us. If one port fits both a REST cashier API and ISO 20022, it will fit the provider you name.
That is a decision we have made and designed for, not something we have shipped — there is no self-host distribution today, and it would be dishonest to call it a delivery mode when it is an intention. What is already true is the part procurement usually asks about: the shared foundations Zygos is built on are MIT-licensed and published on public npm and nuget.org, and the build resolves from those public feeds only. Your build never depends on a private feed that only we can publish to.
Yes — no form, no call, no sales gate. Open https://app.zygos.dloizides.com and sign in as "demo" with the password "ZygosDemo!2026.Try". It is the real product against a real database, not a video or a click-through prototype: real Keycloak login, real API, real Postgres. The demo tenant is seeded with a working day — a few hundred payment instructions across every stage, a full approvals queue, settled payments with their ledger postings, and payments that were re-routed to a second provider after the first refused them. Two things worth trying. First, approve something from the queue: you can, because you did not raise it. Then create your own instruction and try to approve that: you cannot, and neither could anyone who edited it — that is the four-eyes control, and it is the one thing on this page you can disprove in thirty seconds if we are lying. Second, look at any settled payment's audit trail: every state it passed through is there, because there is no other way to move an instruction. Break it as thoroughly as you like — the tenant is designed to be mangled and restores to a clean state on demand.
Honestly: it is early, and we would rather say so here than have you find out in week three. Built, and tested against real Postgres: the instruction lifecycle, contributor-based maker-checker, end-to-end idempotency, the append-only audit trail, counterparty records, a double-entry ledger whose append-only rule is enforced by the database itself rather than by our good intentions, provider routing with automatic failover, reconciliation of provider statements with the breaks worked through the same approval engine as the payments, and one connector port with two protocol shapes behind it. The controls that matter most are mutation-tested — remove them and the tests fail, which is the only version of that claim worth anything. Not built: self-host distribution. It is a decision we have designed for and not something we have shipped, and nothing on this page should tell you otherwise — if it does, tell us and we will fix the page. You do not have to take any of this on trust: the demo above is the same code, and if something we claim here is not in it, we are wrong and want to know. One thing worth knowing about the failover, because it is a real trade we made: it only re-routes when a provider actually answers that it did not take the payment. A timeout means we do not know, so we stop and ask a human rather than risk paying twice — that costs us availability, on purpose. The connectors run as mocks of their published contracts, and Zygos is pre-customer. If you need a vendor with a decade of EMI deployments behind them, we are not that today. If you want to shape a back-office around how your operations actually work, that is exactly what this stage is good for.
Next
The useful version of this conversation is a technical one: your instruction shapes, your approval policy, your providers, and where your current back-office hurts. Zygos is early and pre-customer — if you want a back-office shaped around how your operations actually work, this is the stage where that is still possible.