Swift Hackathon 2026: SpendTheBits’ StableNet named a Technical Challenge finalist for stablecoin compliance control

StableNet, the settlement and compliance layer built by SpendTheBits, has been named a finalist in the Technical Challenge track of the Swift Hackathon 2026. Swift confirmed the finalist list in mid-August 2026, and winners across the Business and Technical Challenge tracks will be announced on October 1 at Sibos Miami, on the Innotribe Stage. The Technical Challenge finalist list also includes teams from established financial infrastructure players and technology firms, alongside StableNet as one of the operating stablecoin payment platforms in the group.

What was the Swift Hackathon 2026 actually testing for?

Swift framed this year's competition around a single theme: scaling digital assets through standards. The Business Challenge track asked teams to address "who does what in a tokenised world" — the commercial and operational question of roles and responsibilities as settlement moves on-chain. The Technical Challenge track asked a narrower, harder question, described by Swift as "cracking the control conundrum": how do regulated institutions keep the oversight they are required to maintain once value itself starts moving on a public, permissionless ledger instead of through a closed banking network they control end to end?

The finalist field is deliberately mixed. Alongside StableNet, the Technical Challenge shortlist includes established financial-infrastructure and technology firms, and the Business Challenge shortlist includes global banks entering their own tokenisation and stablecoin-role submissions. Running the two tracks together, and reviewing a stablecoin payments platform against banks and infrastructure vendors on the same criteria, is itself a signal of how Swift is treating digital-asset settlement in 2026: not as a side project for a narrow set of crypto-native firms, but as a standards problem the entire messaging network has a stake in solving.

What is Swift, and why does its hackathon carry weight?

Swift is the cooperative messaging network that connects more than 11,000 banks and financial institutions across over 200 countries, and it is the standards body behind ISO 20022, the structured financial-messaging format now replacing legacy MT traffic across payments and securities. When Swift runs a hackathon, the submissions are not judged only on whether a demo works — they are judged against the same interoperability and standards bar that governs live SWIFT MT and MX traffic today. That is what separates a Swift Hackathon finalist placement from a generic startup pitch competition: the review panel includes the institution that effectively writes the rulebook for cross-border financial messaging, and the theme this year — scaling digital assets through standards — was chosen because Swift itself is actively working out how tokenised value fits into that rulebook.

What problem does Universal Compliance Control solve?

On a public blockchain, settlement and control are structurally separated. The transfer of a token happens on-chain, recorded on a ledger no single institution operates. The controls that are supposed to govern that transfer — has this wallet been screened, is there valid Travel Rule data for both parties, does this look like a sanctioned counterparty — typically live off-chain, in a compliance system that has no binding relationship to the transaction itself. A bank can run every check it wants before initiating a transfer, but nothing stops the transfer from settling if the check fails, is skipped, or was run against stale data. For regulated institutions moving real value, that gap between settlement and control is the whole problem: it is the reason a public chain, on its own, is not yet a venue a compliance officer can sign off on.

Put concretely: imagine a licensed money service business sending a stablecoin payment to a beneficiary whose wallet was added to a sanctions list an hour earlier. In a conventional architecture, that fact lives in a screening database the compliance team queries separately from the transfer. If the query does not run, runs against a cached list, or runs but nobody blocks the transaction on the result, the payment still settles — irrevocably, on a public ledger, in seconds. The institution then has to prove after the fact that it exercised appropriate controls, using records that were never actually binding on the transfer itself. That after-the-fact posture is what regulators and examiners find hardest to accept about public-chain settlement, and it is precisely the posture Universal Compliance Control is built to eliminate.

How does Universal Compliance Control work?

UCC's answer is to make the compliance check part of the settlement mechanism, not a separate process that happens to run alongside it. The design has two layers that have to agree before value moves.

• An on-chain settlement gate: a transfer only clears once it carries a valid, cryptographically signed attestation. No attestation, no settlement. The gate was built to function across different token types rather than one bespoke asset, and was tested against unmodified USDC — meaning the control layer sits alongside the token as issued, without requiring a special-purpose or wrapped version of the asset.
• An off-chain oracle layer: this is where the actual compliance work happens — sanctions and PEP screening, FATF Travel Rule data exchange in the IVMS101 format, know-your-transaction (KYT) monitoring, and wallet ownership verification. The oracle is fail-closed: if it cannot produce a valid attestation, the on-chain gate has nothing to accept, and the transfer does not settle.
• ISO 20022 messaging carrying the attestation: rather than inventing a new data format for the compliance payload, UCC attaches attestations to transactions using existing ISO 20022 payment and securities messaging structures — the same standards institutions already use for SWIFT MX traffic.

The effect is that a compliance failure becomes a settlement failure automatically, rather than a finding that surfaces in a report after the fact. That is the specific "control conundrum" the Technical Challenge asked teams to crack: not building another off-chain screening tool, but binding the screening result to whether the transfer is even capable of finalizing on-chain.

Once an asset settles on a public chain, the transfer happens on-chain while control has usually stayed off-chain. Universal Compliance Control puts the attestation in the settlement path itself, so a transfer without valid, signed compliance data simply does not clear — on Solana, on an EVM chain, or on the next chain after that.

Why does the fail-closed design matter?

The choice to make the oracle fail-closed, rather than fail-open, is a deliberate and consequential design decision. A fail-open system defaults to letting a transfer through when the compliance check cannot be completed — because the oracle is down, a data source times out, or a lookup errors — which quietly reintroduces the exact gap UCC exists to close: settlement that proceeds without a verified control. A fail-closed system defaults the other way. If the oracle cannot produce a valid, signed attestation for any reason, the on-chain gate has nothing to accept and the transfer simply does not settle. That trades a small amount of availability for a much larger guarantee: nothing moves through the gate without an affirmative, current compliance result behind it. For a compliance officer or an examiner, that guarantee is the entire point — it turns "we believe our screening ran" into "the transaction record proves our screening ran, because it could not have settled otherwise."

What does a settled payment look like in SWIFT terms?

The recorded demo submitted alongside Universal Compliance Control walks through a live payment on StableNet's public sandbox rather than a slide deck. A business logs in, opens the payment wizard, and sends funds through a compliance-first flow — ISO purpose codes, supporting invoice documentation, a KYB-gated sender — with the full fee table (sender fee, receiver fee, platform fee, FX rate) disclosed and server-verified before anything moves, so a tampered or stale quote is rejected outright rather than silently honoured. A funded example in the demo settles for US$100 in USDC on Solana, claimed against its on-chain transaction hash, compliance-reviewed with a documented request-for-more-information round trip, and paid out with the receipt attached — every step timestamped and every compliance remark preserved on the record.

What makes that settlement legible to a bank is what happens next: StableNet projects it as a CBPR+ pacs.008 customer credit transfer, validated against the official ISO 20022 XSD schema, alongside the matching pacs.009 interbank leg, both tracked end to end by a UETR (Unique End-to-end Transaction Reference) and wrapped in a head.001 business application header — the same envelope structure a correspondent bank's own SWIFT traffic would use. Rejections get the same treatment rather than being handled as an afterthought: when compliance declines a payment after funds have already landed, StableNet issues a pacs.004 Payment Return with a coded reason (RR04), the original UETR referenced, and charges disclosed, matching exactly what a correspondent bank would send back through the network. The live sandbox is public at stablenet-sandbox.spendthebits.com for anyone who wants to step through the same flow.

How was it tested, and what did testing find?

StableNet operates an active cross-border stablecoin platform, and the team used that operating experience to test UCC against live conditions rather than a purely theoretical model. The gate-and-oracle design was run on public devnets on both Solana and an EVM-compatible chain, using unmodified USDC in both environments — a deliberate choice to prove interoperability across two materially different chain architectures rather than optimizing for just one. The testing process itself was treated as part of the submission: rather than reporting a clean result, the team documented ten specific industry standards gaps that surfaced during live devnet testing — the concrete places where existing token, messaging or attestation standards do not yet fully support attestation-gated settlement at production scale. Naming those gaps rather than glossing over them is arguably the more useful output of a hackathon built around standards: it tells the rest of the industry, including Swift, exactly where the next round of standards work needs to focus. A technical walkthrough of the demo, recorded for the submission, is publicly available on StableNet's YouTube channel for anyone who wants to see the attestation gate and oracle running end to end.

What do the ten standards gaps mean for the wider industry?

Swift's own framing of the Technical Challenge — "cracking the control conundrum" — assumed the conundrum was not fully solved yet, and the submission treated that as the actual brief rather than something to paper over with a polished demo. The ten gaps surfaced during live devnet testing sit at the seams between systems that were not originally designed to talk to each other: token standards written for general-purpose transfers, attestation formats built for other use cases, and ISO 20022 message types drafted before attestation-gated settlement existed as a pattern. None of that is a defect in any one standard on its own — it is what happens the first time someone actually wires attestation-gated compliance into live settlement on two different chains instead of describing it in a whitepaper. Publishing the friction rather than hiding it is also, in a narrow sense, self-interested: it stakes out StableNet's operating experience as a reference point for exactly the standards work Swift, other Technical Challenge finalists and chain-level standards bodies are likely to take up next.

What does this mean for banks and MSBs evaluating stablecoin rails?

For a bank, credit union or money service business weighing whether stablecoin settlement is fit for regulated flows, a Swift Hackathon finalist placement is a useful, independent data point rather than a marketing claim. It says that the specific mechanism for keeping compliance binding on public-chain settlement was reviewed by the organisation whose messaging standards those institutions already rely on, and that the mechanism worked across two structurally different chains using an unmodified, widely held stablecoin rather than a purpose-built test asset. That is a materially different signal than a vendor asserting its own platform is "compliant by design." It does not replace an institution's own due diligence — licensing status, reserve backing of the settlement asset, audit history and operational track record all still have to be verified independently — but it does narrow the question from "can on-chain settlement ever satisfy a compliance officer" to "does this specific vendor's control model hold up," which is the more tractable question procurement teams are actually equipped to evaluate.

Why does a hackathon result matter for a live payments platform?

A hackathon finalist placement is not a certification, and it is not a customer outcome. What it does confirm is that a specific technical approach — binding compliance attestations to on-chain settlement, expressed in standards institutions already use — held up under independent review by the organization that operates the messaging network most of global banking still runs on. For an operating platform, that matters because it validates the direction of a control model already built into production, rather than describing a hypothetical one designed only to win a competition.

It also matters for a reason specific to this moment in stablecoin settlement. Most of the industry conversation about compliance still treats it as something layered around a transfer — screening run before a payment is initiated, monitoring run after it settles, with the on-chain event itself indifferent to either. Regulators evaluating whether public-chain settlement is fit for regulated flows have been consistent on the gap that creates: a check that can be skipped, delayed or run against stale data is not a control, it is a report. Being recognised for closing that specific gap, by the standards body institutions already trust to define how compliant messaging works, is a different kind of validation than winning on speed or cost alone.

Where StableNet fits

StableNet already combines SWIFT MT and ISO 20022 messaging with compliant stablecoin settlement — KYC, KYB, KYT, sanctions screening and Travel Rule data attached to each payment before it reaches finality. Universal Compliance Control is the same discipline pushed one layer deeper: instead of compliance data merely accompanying a settlement instruction, it becomes a precondition the on-chain transfer itself cannot bypass. Whichever team wins at Sibos Miami on October 1, the ten gaps identified in testing are now a public roadmap for the next stage of that work.