How Four Engineers Built Their Way into the Swift Hackathon 2026 Final
Tokenized assets do not only have an issuance problem. They have a control-layer problem.
A token contract can represent ownership, execute deterministic state changes, and record an event. But financial products do not operate on ownership alone. They operate with permissions, restrictions, approvals, freezes, evidence, and reporting obligations.
That is the problem we explored through UCF, the Universal Control Function, after Nova Pro Tech was shortlisted for the Swift Hackathon 2026 technical challenge, “Cracking the control conundrum.” The challenge asks how reusable, standards-based control functions can work across digital-asset platforms regardless of asset type.
Our starting point was simple: where should control logic live, and how should the result travel beyond the chain?
Sanctions checks, identity validation, transfer limits, approvals, and freeze decisions are not optional edges around a regulated digital asset. They are part of its operating model. Yet they are often recreated inside each token contract, for each asset, and sometimes for every blockchain network.
That produces more than duplicated code. It produces duplicated governance.
UCF is an architectural approach for making that control layer explicit: modular enough to be reused, enforceable at the transfer boundary, observable by external systems, and understandable in the structured language used by financial infrastructure.
The token should not own every rule
A token contract is well suited to representing ownership and enforcing state transitions. It should not have to become a complete policy platform.
When policy logic is embedded directly into every asset, familiar problems appear:
- The same control has to be implemented and reviewed repeatedly.
- A policy change can require multiple upgrades or deployments.
- Similar rules may behave differently across assets or networks.
- Audit and governance effort expands with each implementation.
- Downstream systems receive technical events without a consistent business meaning.
This is a coupling problem. The asset becomes harder to evolve, while the policy becomes harder to govern.
UCF begins from a different principle: an asset and the controls governing it should be able to evolve independently.
Instead of treating every token as a self-contained policy engine, UCF uses reusable control modules. A module can express a defined decision: whether a transfer is permitted, restricted, frozen, or requires further validation. Before an asset changes state, it invokes the relevant controls. The combined decision is then recorded as a structured control event.
The purpose is not to move enforcement away from the blockchain. It is to separate enforcement logic from the identity of a single token.
A control that arrives after a transfer is a report
There is an important distinction between detecting a problem and preventing one.
If a system evaluates a transaction only after an asset has moved, it can still create a useful alert, investigation case, or audit record. But it did not control the transaction.
For a rule intended to decide whether a transfer may occur, evaluation has to happen before the state change. UCF follows a clear sequence:
- A transfer is requested.
- Relevant control modules evaluate the request.
- The asset contract enforces the combined result.
- A structured event records the outcome and reason.
This ordering makes the decision enforceable and observable at the same time.
Not every process belongs on-chain. Screening providers, identity systems, policy administration, and investigative workflows may remain off-chain. The architectural requirement is not to put everything on a blockchain. It is to define an enforcement boundary clearly, so the transfer path cannot bypass the final decision.
Observation should not become authority
Connecting blockchain events to financial infrastructure introduces another design risk: the integration bridge can become too powerful.
If an off-chain component both observes events and controls on-chain state, it expands the trust boundary. A reporting integration can quietly become a privileged execution path.
UCF separates three responsibilities:
- On-chain control modules evaluate and enforce rules relevant to a transfer.
- A read-only event bridge observes structured outcomes without authority to rewrite them.
- A reporting layer maps those outcomes into financial message structures.
Each layer has a narrower purpose. Smart contracts remain responsible for deterministic enforcement. The bridge transports facts. The reporting layer gives those facts business meaning.
That separation makes the flow easier to reason about, test, and govern. It also lets a team assess failure modes more precisely. A delayed reporting message is not the same as a failed transfer control; an unavailable observer should not silently alter asset state.
A blockchain event is not yet a financial message
An on-chain event may contain a transaction hash, contract address, account identifiers, and a machine-readable result. A bank, custodian, compliance team, or market infrastructure typically works with a different vocabulary: parties, statuses, reasons, references, and defined message structures.
Get Nova Information Technologies’s stories in your inbox
Join Medium for free to get updates from this writer.
The integration challenge is therefore semantic as much as technical.
UCF maps control outcomes into ISO 20022-aligned message structures through deterministic transformation rules. This does not mean that a blockchain transaction and an ISO 20022 message are the same object. They are not.
The objective is to preserve the meaning of a decision as it crosses from one environment into another.
A rejected, restricted, approved, or frozen transfer should not become an ambiguous log entry that every institution interprets differently. The control type, subject, outcome, reason, source event, and relevant references should travel together as a traceable result.
This is where standards matter. Swift’s briefing material frames ISO 20022 as a common model for transaction instructions and token representation across platforms and ecosystems. Swift Hackathon 2026 briefing pack
Asset-agnostic does not mean chain-blind
“Chain-agnostic” is often used as shorthand for deploying similar software on several networks. For a control function, that is not enough.
The more useful question is whether the control model depends on the identity of a particular chain or token.
UCF is designed around structured control requests and outcomes. Across environments, the stable questions remain:
- Which control was evaluated?
- Which parties and asset were involved?
- What decision was produced?
- Why was it produced?
- Which event proves that result?
- How should it be represented outside the chain?
This does not erase network-specific engineering. Finality, event delivery, account models, contract interfaces, and operating constraints still differ. An asset-agnostic architecture should acknowledge those differences rather than hide them.
What it can provide is a stable model above them: common semantics, replaceable adapters, and modules that are not permanently fused to one asset implementation.
What the two-week build changed
The hackathon did not ask only for an architecture diagram. Shortlisted teams entered a two-week build phase to develop a solution and supporting material.
That constraint was useful. Architecture diagrams are generous; working flows are not.
The build forced concrete decisions:
- where control evaluation ends and token enforcement begins;
- how multiple control results are combined;
- which data belongs in an event and which remains off-chain;
- how a bridge observes outcomes without becoming a source of authority;
- how on-chain identifiers map to ISO 20022 concepts; and
- how the same model can survive a change in asset or network.
These decisions matter more than the surface of a demo. They determine whether a control layer can remain reusable once it leaves a single proof of concept.
What being shortlisted means — and what it does not
Being selected for the technical challenge is a meaningful milestone. It provides a demanding scope, a short delivery window, and a standards-oriented setting in which to test the design.
It does not mean that the architecture is finished, production-certified, or endorsed by Swift as a complete solution. Those are much larger claims.
The more useful outcome is architectural clarity: a sharper boundary between the asset, the decision that governs it, and the systems that must understand the result.
Tokenized assets will not reach operational maturity through issuance contracts alone. The controls around them need to be reusable, reviewable, enforceable, observable, and capable of communicating with established financial systems.
That boundary is the control layer.
Explore the UCF architecture and project overview: Universal Control Function — Nova Pro Tech
Editorial source and verification notes
- Swift confirms the technical challenge wording, the “up to five teams per challenge” shortlist structure, the two-week build phase, and the Sibos presentation opportunity. Official Hackathon page
- Swift’s June 2026 briefing pack supports the standards and ISO 20022 context. Briefing pack
- Before publishing, confirm internally: Nova finalist status, “four engineers” title claim, 27 July submission date, testnet evidence, and precise UCF implementation details.
- Do not describe UCF as Swift-certified, production-ready, or Swift-endorsed.
