Security by architecture.Not by policy.
Tekmerion holds no funds — not even funds under review. What settles is the merchant's to decide.
Security and risk are usually handled with policy: promises about what a system will not do, and reviews that hold funds while someone decides. Tekmerion handles them with structure instead. The states where funds are lost, frozen, or misdirected are removed from the architecture — so there is less to police, and less to take on faith.
Tekmerion cannot lose, freeze, or misdirect merchant funds, because it never holds them. There are no internal balances to drain, no custodial accounts to compromise, no settlement pool to attack.
Funds move directly from payer to merchant, and the only instruction that moves them is one the merchant signed. Tekmerion relays it and has no discretion of its own. This is not a guarantee Tekmerion makes — it is a capability the system does not have. A service with no custody cannot mishandle what it was never given.
A crypto payment cannot be stopped before it arrives. The payer sends to the deposit address whenever they choose, and the funds land on-chain. So screening does not happen before the funds arrive — it happens around a deposit that is already there.
What makes that safe is what is absent: no one is holding it. The deposit sits at an address that runs no code and that Tekmerion holds no key to. It is screened for sanctions and risk signals while it sits there, in no one's custody. Then the merchant decides whether the payment proceeds — and only on the merchant's authorization does it settle to them.
In a custodial processor the same sequence is the dangerous one: the funds arrive into the provider's account and are held there through the review. Suspect money sits in custody; clean money is frozen beside it; the provider carries the exposure and the merchant waits. Tekmerion screens the same deposit with none of it held by anyone. The risk window exists in legacy systems because custody exists. Without custody, the window is closed.
Tekmerion screens. It does not adjudicate. The signals it raises — sanctions exposure, risk indicators on the source of funds — inform a decision that belongs to the merchant, and it is a gate, not a complete compliance program.
For a licensed business this is as it must be. The AML and licensing obligations are the merchant's, and so is the call on any given payment. Tekmerion does not assume that obligation, hold funds to enforce it, or decide in the merchant's place. It surfaces what the merchant needs in order to decide, records the decision against the payment, and acts only on the authorization that follows.
The infrastructure around the payment is secured the same way — by limiting what is possible, not by trusting what is promised.
Merchant API keys control programmatic access. Each key is scoped, revocable, and independent; revoking one affects nothing else. Access is deny-by-default — an endpoint with no registered key receives nothing.
Outbound events are signed. Every webhook carries a signature the merchant verifies before acting on it, and an unsigned or altered payload is rejected. The merchant never has to trust that a message came from Tekmerion — they can check.
Policy asks you to trust that a system will not do the wrong thing.
Architecture removes the wrong thing as an option.