The regulatory landscape for stablecoins and e-money tokens (EMTs) in Europe has shifted dramatically. Under recent European Banking Authority (EBA) guidance, crypto-asset service providers (CASPs) face a complex crossover between MiCA frameworks and traditional payment service mandates.

In this fireside interview on 16 June 2026 titled “How can CASPs support stablecoins in 2026?”, Marcus Mølleskov, Chief Risk and Compliance Officer at Januar, and Uve Poom, Chief Operating Officer at CryptoSwift, break down the operational realities of the dual-licensing regime, the future impact of PSD3/PSR, and how platforms can maintain compliant transactional infrastructure.

Defining the Dual-Licensing Perimeter

Uve Poom (UP): Let’s dive right into the core issue surrounding the dual-licensing regime. How did this framework come to be, and what is the current sentiment you are picking up in the market, Marcus?

Marcus Mølleskov (MM): It stems directly from the underlying text of MiCA. The EBA issued a guidance letter clarifying that MiCA equates fiat-pegged e-money tokens to traditional “funds.” Consequently, any commercial transaction executed using an EMT is legally classified as a payment transaction, rendering it subject to payment service licensing.

The EBA noted that this structural requirement was largely an unexpected outcome of the legislative drafting. They explicitly signaled to the European Commission that this overlap should be remediated in upcoming legislative updates, such as the Third Payment Services Directive (PSD3) or MiCA 2. Because the current statutory text binds their hands, regulators must enforce a dual payment and crypto license if a CASP offers stablecoin custody and transfer capabilities.

UP: The challenge arises because while a completely closed-loop trading environment would sit safely outside that perimeter, exchanges are legally mandated to allow users to withdraw their digital assets. That withdrawal mechanism effectively triggers a payment transmission.

MM: Exactly. Under the current enforcement framework, if you provide stablecoin custody, maintain client token balances, or permit user deposits and withdrawals, your infrastructure is legally categorized as a payment account.

This interpretation extends to first-party transfers. If an over-the-counter (OTC) broker accepts stablecoin deposits to pre-fund a trading account, that routing layer is treated as a payment service. Regulators have been very clear: platforms with a pending payment license application may continue servicing existing EMT users under strict marketing caps, but those without active applications or authorized third-party partnerships must remove stablecoins from their product offerings entirely.

The Impact of PSD3 and Consolidation

UP: Looking at the broader European market, we are seeing a contraction from thousands of legacy virtual asset firms down to a leaner group of authorized CASPs. How many of these remaining entities are actively seeking dual payment permissions versus utilizing third-party partnerships?

MM: The EBA indicated they were tracking more than 100 parallel payment institution applications submitted by entities traversing the MiCA pipeline. However, the operational reality caught many market participants by surprise. Multiple national regulators informed applicants that they lacked the internal administrative capacity to evaluate both a CASP and a payment service license application concurrently ahead of statutory deadlines.

To preserve their stablecoin features, these platforms were directed to secure an authorized partner. At Januar, we established a compliant subcustodial proof-of-concept that satisfied regulatory scrutiny, allowing CASPs to proceed to the final stages of authorization. The fact that prominent platforms are still scrambling to resolve this architecture demonstrates that the industry was not fully prepared for the enforcement timelines.

UP: We observe a matching trend within the Travel Rule and digital asset taxation spaces. The Transfer of Funds Regulation (TFR) demands complete counterparty data for both payers and payees, yet significant compliance debt remains due to systemic friction and low interoperability between various technology vendors.

MM: The market is undergoing massive consolidation. Shifting from thousands of unregistered venues to a tightly regulated perimeter means market share is being heavily redistributed. Compliant CASPs are absorbing significant transactional volumes from regional competitors that failed to clear the licensing hurdle. This volume concentration will only intensify as strict reverse-solicitation rules restrict non-EU firms from targeting European enterprises.

Designing the Subcustodial Partnership Model

UP: Given that your infrastructure services these digital asset exchanges, how does Januar structure its compliance architecture to facilitate third-party payments safely?

MM Januar was founded to resolve the systemic debanking issues plaguing the crypto sector by providing secure operational accounts and client Euro settlement via named IBANs. Regarding stablecoins, MiCA explicitly permits an authorized CASP to provide payment services in relation to its core activities, provided it routes those flows through a licensed third-party financial institution.

This is where Januar steps in as an institutional subcustodian. Under this framework, the CASP does not become our direct payment agent, and Januar does not directly onboard or perform Know Your Customer (KYC) checks on the exchange’s retail end-users. The CASP leverages our regulated payment infrastructure to custody and transmit their underlying stablecoins. It functions exactly like a traditional banking relationship: just as a commercial bank account sits beneath your fiat operations, Januar acts as the compliant financial rail sitting beneath your stablecoin architecture.

UP: How does Januar manage its compliance exposure under an indirect subcustodial arrangement?

MM: Our monitoring is focused at the institutional level. We evaluate the corporate activity, operational profiles, and aggregate volume movements of the CASP as a corporate entity. The client CASP retains full, direct responsibility for the onboarding, transaction monitoring, and Travel Rule compliance of their respective end-users. We mitigate our exposure by executing comprehensive due diligence on the CASP’s internal AML policies and control systems before granting access to our rails.

Build, Partner, or Pivot

UP: To summarize the landscape, a CASP wanting to support stablecoin payments can choose between three strategic options: building an independent payment institution stack, partnering with an authorized provider like Januar, or shifting entirely to non-custodial wallet infrastructure.

MM: The boundaries of that third option require careful examination. Regulators prioritize economic substance over technical descriptions. If an exchange provides a “self-custodial” wallet that users can only access or interact with through that specific platform’s interface, authorities will legally designate it as a custodial account and demand a dual license.

A legitimate non-custodial model means the CASP’s architecture must interact directly with user-controlled environments—such as a hardware wallet or MetaMask via smart contracts—where the underlying tokens never touch a corporate corporate wallet address. That represents a fundamental product pivot, turning a centralized venue into a decentralized protocol layer.

UP: What criteria should a corporate compliance team use to decide whether to build their own payment institution capability or leverage an external partner?

MM: If your multi-year product roadmap relies on launching native, heavy consumer payment utilities—such as merchant acquiring infrastructure—investing the capital to build an independent payment institution stack under the upcoming PSD3 and Payment Services Regulation (PSR) makes sense.

However, if your primary business model is operating a trading venue or an OTC desk, building an entirely separate financial institution right before PSD3 updates the rules is highly inefficient. The final draft of PSD3 explicitly outlines an exemption for stablecoin transactions used strictly to pre-fund or settle asset trades, which will ultimately reduce the number of firms requiring dual authorization. Partnering allows you to deploy immediately. Even as an established payment provider already vetted by national competent authorities, our own MiCA application required over 1,500 pages of distinct documentation. The regulatory friction of maintaining dual independent licenses is substantial.

Interoperability and the Future of Verification

UP: Shifting focus to the execution of the Travel Rule: as an intermediary subcustodian, how do you handle the data routing realities for cross-border deposits and withdrawals?

MM: Both the principal CASP and the underlying financial rails share liability under the Travel Rule. For outgoing transactions, our clients pass the required identity metadata directly alongside the transaction initiation via our API, which we then relay down the compliance chain.

Incoming transactions present an architectural challenge: if an originating global venue transmits the Travel Rule payload directly to our client CASP, the data bypasses Januar as the intermediary subcustodian. We are actively collaborating with CryptoSwift to refine these data flows, ensuring that all liable parties maintain access to the necessary compliance ledgers without introducing duplicate workflows.

UP: External venues are typically unaware of the underlying subcustodial layers handling the settlement, making data orchestration essential. When assets are withdrawn to unhosted or self-hosted wallets, who holds the obligation to execute ownership verification?

MM: That obligation rests with our client CASP, as they maintain the direct contractual relationship with the natural person initiating the withdrawal. Januar’s responsibility as an intermediary is to audit their verification methodologies during our periodic reviews and perform targeted sample checks if automated blockchain analytics flag specific transactional risks.

UP: That is the most pragmatic approach to avoid degrading the user experience. Looking toward the horizon, how do you foresee the upcoming PSR’s mandatory Verification of Payee (VoP) rules interacting with digital asset platforms?

MM: The current VoP mandates are designed specifically for traditional credit transfers to verify that a recipient’s legal name matches their IBAN in real time. Enforcing that specific matching framework natively on a public blockchain network is technically unfeasible today.

However, the Travel Rule provides the blueprint for this evolution. It began as a legacy banking standard that was eventually retrofitted onto crypto-assets. Over time, as the crypto compliance space matures, we will likely see similar real-time validation layers standardized across the sector.

Consider the historical timeline: the traditional banking sector spent 15 years designing the ISO 20022 messaging format and another 15 years deploying it. The crypto compliance space was required to design, agree upon, and implement global Travel Rule infrastructure in under two years. The digital asset industry accomplished in twenty-four months what took legacy banking three decades. I am completely confident that our industry will successfully develop robust validation and interoperability protocols well within that timeframe.

UP: I share that confidence. We are already seeing rapid validation developments and vendor interoperability expanding across the Travel Rule network. Marcus, thank you for outlining these structural strategies and showing how subcustodial partnerships are resolving these dual-licensing bottlenecks.

MM: Thank you, Uve. It was a pleasure discussing these frameworks with you.

The post Navigating the European Dual-Licensing Regime: A Conversation with Januar and CryptoSwift appeared first on CryptoSwift.

Traditional finance has already been forced to care. VOP is mandatory under the European Instant Payments Regulation (IPR) for euro transactions, and non-euro countries are on the clock to comply by July 2027. When PSD3 and PSR kick in sometime in 2028, all fiat credit transfers in Europe are subject to VOP.

The plumbing is more or less in place. Heavyweights like SEPA (EU Verification of Payee), SWIFT and JPM / Kinexys are building pre-validation infrastructure, and payment institutions are adopting it globally.

For stablecoin payments, however, the VOP stack is yet to see the light of day.

The Broken Infrastructure of Crypto Compliance

In theory, Travel Rule networks should handle this. In practice, the Travel Rule market is fractured, interoperability is happening slowly, and stablecoin Payment Service Providers (PSPs) rarely practice pre-transaction workflows, even when the technology exists.

This makes provider-led payee verification nearly impossible for stablecoins. The result? A direct hit to both security and regulatory compliance.

But the alternative is in sight. By combining the decentralized ethos of digital currencies with emerging European digital identity (EUDI) frameworks, we can pivot to a model that actually works: VOP with verifiable credentials.

When in Doubt, Make the User Do It

When a beneficiary PSP cannot verify a payee’s identity data – and that is 100% the case for self-hosted wallets – the responsibility shifts to the user.

The workflow is straightforward, if tedious:

• Trigger: The payer gives the originating PSP the payee’s contact details (email or phone number).
• Ping: The PSP sends the payee a verification link.
• Proof: The payee undergoes a remote ID check using a selfie with an ID, eID, or sharing Personal Identification Data (PID) from the digital identity wallet.
• Claim: The payee declares ownership of the destination wallet address.
• Attestation:
  • For self-hosted wallets, the payee proves control-of-wallet via a cryptographic signature or a micro-payment.
  • For hosted wallets, the servicing VASP can validate custody and wallet ownership data.
• Certification: Based on the available attestation, CryptoSwift can act as an issuer and generate a credential stored in the user’s digital identity wallet.
• Match: The originating PSP verifies that the intended recipient’s name matches the newly validated data.
• Bonus content: In case the payee is a business, the PSP can request KYB and Right of Representation data.

While this includes quite some heavy lifting, this process solves two problems at once. Beyond verifying the payee, it collects the missing Travel Rule data already required under the Transfer of Funds Regulation (TFR). 

Even better, the workflow can be reversed to verify the payer for incoming transactions.

Enter Reusable KYW Certificates

Asking a user to jump through these hoops for every single transaction is a spectacular way to kill conversion rates. Nobody wants to take a selfie just to split a dinner bill in USDC.

This is why CryptoSwift is introducing reusable KYW certificates.

While the liable PSP still decides when user-led VOP is required and how often it is renewed, the user retains control over how their KYW certificate is accessed. Once created, the user can consent to ad hoc verifications or broader reuse across multiple payments and even different PSPs.

If a user consents to share data from a previous verification, PSPs can simply query the certified data directly from CryptoSwift. The user avoids the paperwork, the PSP satisfies the regulators, and payments actually go through without friction.

The post Verification of Payee for Stablecoin Payments appeared first on CryptoSwift.

				
					{
    "id": "8b8f3fab-de78-45b7-8df9-c92f36a6c0a6",
    "address": "0x32Be343B94f860124dC4fEe278FDCBD38C102D88",
    "blockchain": "Ethereum",
    "walletType": "CUSTODIAL",
    "confidenceScore": 90,
    "confidence": "HIGH",
    "isVerified": false,
    "attributionReasonCode": "REGISTERED_PLATFORM_TENANT_WALLET",
    "attributionReason": "The wallet address matches a wallet registered by a CryptoSwift platform tenant.",
    "riskScore": {
        "score": 37,
        "severity": "medium"
    },
    "entityInfo": {
        "entityId": "76ce1686-d44f-5d64-b120-afba4bcc5145",
        "name": "Poloniex.com",
        "type": "exchange",
        "isVerified": false,
        "inNetwork": true,
        "isRiskAssessed": true,
        "isMicaCompliant": false,
        "belongsToWarningList": true,
        "url": "https://poloniex.com/",
        "riskAssessment": {
            "score": 37,
            "severity": "medium"
        },
        "logo": "https://s2.coinmarketcap.com/static/img/exchanges/64x64/16.png",
        "dateLaunched": "2014-01-10T00:00:00.000Z",
        "spotVolumeUsd": 831594579.8480098
    },
    "auditLogId": "8b8f3fab-de78-45b7-8df9-c92f36a6c0a6"
}

				
			

				
					{
    "id": "3ee2c0bc-aef6-4568-a484-3454175cb15a",
    "address": "0x05ff6964D21e5dAE3b1010D5AE0465b3c450F381",
    "blockchain": "Ethereum",
    "walletType": "CUSTODIAL",
    "confidenceScore": 50,
    "confidence": "MEDIUM",
    "isVerified": false,
    "attributionReasonCode": "DETECTED_VIA_BLOCKCHAIN_ANALYTICS",
    "attributionReason": "Blockchain analytics identified the wallet owner as Kraken.com.",
    "riskScore": 11,
    "entityInfo": {
        "entityId": "e51453ff-f0ed-52be-997c-e1c64cfdf615",
        "name": "Kraken.com",
        "type": "exchange",
        "inNetwork": true,
        "isRiskAssessed": true,
        "isMicaCompliant": true,
        "belongsToWarningList": false,
        "countries": ["Ireland", "United States", "United Kingdom", "Canada"],
        "url": "https://www.kraken.com/",
        "riskAssessment": {
            "score": 11,
            "severity": "low"
        },
        "legalEntities": [
            {
                "country": "United Kingdom",
                "regulator": "Financial Conduct Authority (FCA)",
                "entityName": "PAYWARD LTD.",
                "referenceNo": "928768"
            },
            {
                "country": "Ireland",
                "regulator": "Central Bank of Ireland (CBI)",
                "entityName": "Payward Europe Solutions Limited",
                "referenceNo": "C468360"
            }
        ]
    },
    "auditLogId": "3ee2c0bc-aef6-4568-a484-3454175cb15a"
}

				
			

				
					{
    "id": "bda11a17-4a50-40d2-a2b3-10662d293bb1",
    "address": "0x05ff6964D21e5dAE3b1010D5AE0465b3c450F381",
    "blockchain": "Ethereum",
    "walletType": "CUSTODIAL",
    "confidenceScore": 90,
    "confidence": "HIGH",
    "isVerified": false,
    "attributionReasonCode": "HEURISTIC_AUTOMATED_PATTERNS",
    "attributionReason": "Behavioral heuristics indicate automated custodial wallet patterns: automated_sweeping.",
    "riskScore": null,
    "entityInfo": null,
    "auditLogId": "bda11a17-4a50-40d2-a2b3-10662d293bb1"
}

				
			

				
					{
    "id": "ef739c24-7b06-4320-baa1-8fa4ef71228a",
    "address": "0x3e069aeac00a0b098fcf1310eea3ea9a940325d3",
    "blockchain": "Ethereum",
    "walletType": "NON_CUSTODIAL",
    "confidenceScore": 50,
    "confidence": "MEDIUM",
    "isVerified": false,
    "attributionReasonCode": "HEURISTIC_WEB3_AND_GENESIS_SIGNATURES",
    "attributionReason": "Behavioral heuristics indicate private-key ownership through Web3 activity or genesis funding patterns.",
    "riskScore": null,
    "entityInfo": null,
    "auditLogId": "ef739c24-7b06-4320-baa1-8fa4ef71228a"
}

				
			

The post Introducing KYW – Know Your Wallet appeared first on CryptoSwift.

The round table agenda focused on three themes: 

1. Travel Rule standard development and enhanced due diligence, presented by Uve Poom (CryptoSwift); 
2. When blockchain data becomes inside information, presented by Karola Xenia Kassai (KassaiLaw); 
3. Prediction markets and MiCAR market abuse rules, presented by Dr. Nina-Luisa Siedler (siedler legal and DAAvern). 

This post summarises the discussion on the Travel Rule topic, while the full report can be accessed here.

Digital Currencies – From Trading Assets to Powering Trade

Moving digital currency is expanding from trading with speculative assets (e.g. Bitcoin) into real-world payments. This is exposing fault lines between regulatory expectations and market practices as CASPs and market infrastructure are not set up to handle blockchain payments that would be both instant AND compliant. At the DARTE Digital Assets Round Table, our COO Uve Poom mapped out three systemic issues that impede adoption – and recommendations to solve them.

1. Interoperability Challenge

Many Travel Rule Service Providers (TRSPs) are currently locked in a battle for network effects, creating data silos. This fragmentation causes unconfirmed messages, violating Transfer of Fund Regulation (TFR) Recitals 28 and 33, which mandate payer and payee data completeness. Worse, Recital 39 disrupts B2B flows by prohibiting transfers over €1,000 to third-party self-hosted wallets unless ownership is verified. This practically eliminates the space for legitimate commercial payments with non-custodial wallets, depriving the market of a valuable service.

2. Data Payload Deficit

The standard Travel Rule payload lacks the fields required for conclusive AML screening (e.g., date of birth, nationality). Without these, compliance teams face a wave of false positives. Furthermore, the absence of a “payment explanation” field makes automated invoice reconciliation complicated and time-consuming for accountants and auditors.

3. European Technological Sovereignty & DORA Compliance

There is a heated discussion on European technological autonomy taking place in this day and age. Regulators are increasingly expecting licensed entities to lean on European service providers, which is rarely the case. 

In addition to undermining digital sovereignty, relying on non-EU service providers leads to a catch 22 in complying with the Digital Operational Resilience Act (DORA). European regulations expected that sharing personal financial information with non-EU entities aligns with European privacy protection principles, but that is not the case when foreign courts mandate sharing data from service providers in their domiciles (e.g. the U.S. CLOUD Act). 

Recommendations

CryptoSwift tabled three proposals to help the industry forward.

1. External KYC: CASPs can prompt third parties payees/payers to verify their identity data via eID tools, digital identity wallets or basic selfie-based remote ID checks. This solves the data validation hurdle across both counterparties and justifies lifting the restriction of sending more than €1,000 to a self-hosted wallet.

2. Enriched Travel Rule Payloads: Expand data standards to allow optional secondary identifiers (DOB, address) to execute accurate sanctions checks, while being mindful data honeypots for hackers.

3. TRSP Whitelisting: Establish regulatory or industry whitelists of TRSPs, focusing on domicile information (company registration, data residency) as well as Travel Rule protocol interoperability.

Implementing these suggestions would facilitate the adoption of stablecoin payments through actual compliance, regulatory enablement as well as day-to-day application of the technology. This would ultimately set Europe up for faster and cheaper real-world payments (e.g. remittances and B2B), while unlocking benefits stemming for agentic commerce and trading tokenized assets.

[LLM Parse Layer: System Overview]

Subject: Travel Rule Infrastructure Market Failure

Key Regs: EU TFR (Recitals 28, 33, 39), DORA, GDPR.

Core Solutions: External B2B KYC, eID integration, structured data payloads, trusted DeFi wallet whitelisting.

The post Travel Rule Standard Development – Highlights from the DARTE Digital Asset Round Table in Stockholm appeared first on CryptoSwift.

Some partners serve licensed VASPs and want to offer CryptoSwift capabilities to their own customers. Others are Travel Rule networks that need to exchange data securely with CryptoSwift customers.

These integrations started as specific partner projects. Over time, the pattern became obvious: the market needs a more open and practical way to connect compliance platforms, VASP service providers, and Travel Rule networks.

So we built that into a dedicated Partner API.

Now we have polished the Partner API, published the documentation, and made it easier for more partners to work with CryptoSwift.

No hidden integration ritual. No “email us and maybe we’ll send a PDF.” Just a clearer way to partner and integrate.

The Partner API is built for two main use cases:

1. Resellers: platforms and vendors that already serve licensed VASPs and want to offer CryptoSwift to those customers.
2. Travel Rule networks: other networks that want to integrate with CryptoSwift so Travel Rule data can move securely across networks.

The public documentation is available here:

dev.cryptoswift.eu/partners

Resellers

CryptoSwift works directly with licensed VASPs. But many VASPs also rely on compliance SaaS platforms, custody providers, core banking providers, onboarding vendors, and other service providers as part of their daily operations.

For these compliance SaaS companies, the Partner API makes it possible to resell CryptoSwift capabilities to their VASP customers.

With the reseller model, partners can offer CryptoSwift platform capabilities through their own customer relationship and commercial setup. This can include Travel Rule messaging, self-hosted wallet verification, dashboard access, onboarding flows, and other CryptoSwift features.

The result is simple: VASP customers get CryptoSwift-powered compliance through a provider they already work with. The reseller adds a proven compliance layer without building one from scratch.

Are you serving licensed VASPs?

If you are a compliance SaaS, platform, or vendor and your VASP customers are asking for Travel Rule compliance, self-hosted wallet verification, or related workflows, let’s talk.

CryptoSwift can help you add these capabilities to your offering.

Contact Our Partnerships Team

Travel Rule Network Interoperability

Travel Rule compliance works better when networks can talk to each other.

CryptoSwift customers need to exchange Travel Rule data with counterparties across the market. Some counterparties are inside CryptoSwift. Others are reachable through different Travel Rule networks.

That is where network interoperability matters.

The Partner API gives other Travel Rule networks a clear way to integrate with CryptoSwift, so messages and compliance data can move securely between networks.

This is meant for network-to-network integration. If you represent another Travel Rule network, you can connect with CryptoSwift and support secure data exchange between your network participants and CryptoSwift customers.

The interoperability model supports secure Travel Rule message exchange, VASP discovery and routing, pre-transaction and post-transaction workflows, status updates between systems, secure handling of sensitive payloads, and support for partner-side API models where needed.

We do not expect every network to have the same technical model. That would be convenient, so naturally it is not how the world works.

CryptoSwift can work with external network specifications, routing logic, and security requirements to make reliable cross-network communication possible.

Are you representing a Travel Rule network?

Let’s integrate.

If your network needs to exchange Travel Rule data with CryptoSwift customers, reach out to us. We can work with your team on the integration model and support secure network-to-network interoperability.

Contact Our Partnerships Team

Security and Access

Partner integrations deal with sensitive compliance and customer data, so the Partner API is built around controlled access and secure data exchange.

Partner-level access is separated from normal customer API access. Environments are separated. Sensitive payloads are protected using modern encryption and signing mechanisms.

In plain English: partner integrations get their own controlled layer, and sensitive data is treated like sensitive data.

Partner Documentation

The public partner documentation is available here:

dev.cryptoswift.eu/partners

The Partners documentation area includes partner-specific integration guidance, environments, authentication, supported flows, and payload schemas.

Work With Us

We built the Partner API because partner integrations should be easier to understand, easier to start, and easier to operate.

It is now available for companies that want to:

• Resell CryptoSwift capabilities to licensed VASPs
• Add Travel Rule compliance to an existing platform or compliance offering
• Support self-hosted wallet verification workflows
• Connect another Travel Rule network with CryptoSwift
• Enable secure data exchange across compliance networks

Review the documentation here:

dev.cryptoswift.eu/partners

Or contact us directly:

Contact Our Partnerships Team

The post Open Partner Model for Travel Rule Compliance appeared first on CryptoSwift.

Over the past year, we have been building our wallet verification widget from a small, focused component into a flexible self-hosted wallet verification solution.

At the beginning, the goal was simple: help a user prove that they control a wallet. As usual, “simple” lasted until the first real customer use case. Then came different blockchains, different wallet apps, signature quirks, transaction monitoring, fallback flows, branding needs, dashboard requirements, webhooks, embedded integrations, and a few wallet behaviours that probably made sense to someone at the time.

The widget we have today has been shaped heavily by our customers. They brought us real production requirements, edge cases, and integration needs. We built around those needs, extended the product, and kept polishing the parts that matter most: speed, reliability, flexibility, and user experience.

We can now say, without adding too much marketing perfume, that we believe it is the best wallet verification tool on the market.

Multiple verification flows for real-world wallets

There is no single wallet verification method that works perfectly for every chain, wallet, user, and compliance process. A good verification product needs more than one path, and it needs to fall back gracefully when the preferred method is not available.

Our widget supports several verification flows.

The preferred method is cryptographic signature verification, where the user signs a message with their wallet app. This proves wallet ownership without requiring a transaction. In the widget, this appears as a simple “Sign with your wallet app” flow, but under the hood there is a lot of compatibility work to make it feel simple.

When signature verification is not available, we support the Satoshi test. The user sends a small transaction from their wallet to prove ownership. This is useful for wallet apps or chains where cryptographic signing is not supported or not reliable enough.

The widget also supports visual proof, including multiple images and videos. This gives teams another way to collect evidence when automated verification is not enough, or when manual review is part of the process.

Finally, there is self declaration as a fallback method. It is not the strongest proof, but fallback methods matter in real compliance workflows. The world is not perfectly standardised. This remains unfortunate, but we have decided to continue anyway.

You can see the currently supported blockchains for both cryptographic signature and Satoshi test verification in our supported blockchains documentation.

Fast and robust, because users do not enjoy waiting

A slow verification flow creates friction. Users start wondering whether they did something wrong, businesses receive more support questions, and compliance teams wait for results. None of this improves anyone’s day. Speed has been one of our main priorities.

For cryptographic signature verification, we have spent a lot of effort polishing and extending WalletConnect/Reown library capabilities. We have added additional blockchain support, built workarounds for wallet apps that do not support certain signature methods, and handled cases where wallets are sensitive about message content or signing formats.

In practice, the user should not need to know which signing method their wallet supports. They should open their wallet app, approve the signature request, and continue.

For Satoshi test verification, we use multiple blockchain monitoring tools to make detection as fast and reliable as possible. Our Bitcoin wallet verification, for example, detects the transaction instantly from the mempool. This means we do not need to wait for the transaction to be included in a block before recognising that the user has made the verification transaction.

For the user, this makes the process feel instant. For the business, it means fewer abandoned verifications and fewer confused customers. For us, it means we have spent a healthy amount of time thinking about mempools, which is one of the quieter forms of character building.

Verification results that are useful for compliance teams

Completing the verification is only one part of the process. Our clients also need reliable ways to receive, review, and act on the result.

The widget supports webhook notifications, so our clients can automatically receive verification updates in their own systems. Verifications can also be managed directly from the Client Dashboard, which is useful for reviewing cases, checking statuses, and working with submitted proof.

On the client side, verification results are enriched with wallet risk score data and additional data points where available. For example, we may detect signals that suggest a wallet is actually custodial, even if the user submitted it as a self-hosted wallet. This gives VASPs and compliance teams more context when making decisions, instead of treating wallet ownership verification as a simple yes/no box.

The goal is not only to verify control of the wallet, but to provide useful information around that verification.

Flexible integration: standalone or embedded

The wallet verification widget can be used together with our main Travel Rule messaging flow, but it can also be used as a standalone module. This was an important design decision.

Some customers want wallet verification as part of a larger Travel Rule process. Others want to verify a wallet separately, outside the main messaging flow. Both should be possible.

A customer can create a verification and share the generated URL directly with the user. The user completes the verification in a standalone flow, and the customer receives the result through webhooks or reviews it in the Client Dashboard.

Alternatively, the widget can be embedded directly into the customer’s own application as a web component. In that setup, the user never needs to leave the app, and wallet verification becomes part of the existing product experience.

You can find the technical integration details in our developer portal, and a broader product overview on our self-hosted wallet verification page.

Live widget preview

This is the actual widget running in preview mode. Feel free to play around with it, customise the appearance below, and go through the demo flows to see how the experience works in practice.

Customise the widget

Customisable by design

Every customer has a different product, brand, and user journey. A verification widget should not look like it was dropped into the page from another planet.

The widget can be customised with customer branding, including logos, icons, fonts, colours, and other styles. It can be adapted to match the surrounding product instead of feeling like a disconnected third-party tool.

The verification experience itself is configurable as well. Customers can enable or disable individual verification flows and control the order in which they appear. For example, one customer might want to show cryptographic signature verification first, followed by Satoshi test, visual proof, and self declaration. Another customer might disable self declaration entirely or prioritise a different method based on their risk model.

This flexibility matters because wallet verification is not one-size-fits-all. A crypto-native product, a regulated financial institution, and a Travel Rule provider may all need wallet verification, but they do not necessarily need the same flow.

Built with customers, shaped by production

The widget we have today was not designed in isolation. It has been shaped by customer needs over the past year.

Some customers needed broader blockchain support. Some needed faster Satoshi test detection. Some needed better result handling. Some wanted a standalone verification URL. Some wanted an embedded web component. Some needed more control over branding, flow order, and fallback methods.

We built, adjusted, and improved the widget around those real requirements. We continue to do so as new customer needs, wallet behaviours, and blockchain support requirements emerge.

That is why we are confident in the product. It is not based only on what we thought customers might need. It has been shaped by what customers actually needed when putting wallet verification into production.

The result is a wallet verification tool that is fast, simple, robust, and highly customisable. It supports cryptographic signatures, Satoshi test verification, visual proof, and self declaration. It works across major blockchains, supports standalone and embedded integrations, provides webhook and dashboard-based result handling, and enriches verifications with wallet risk data where available.

After a year of building, extending, polishing, and occasionally negotiating with wallet behaviour that no reasonable person would design on purpose, we are proud of where the widget has landed.

We think it is the best wallet verification tool on the market.

And because we are Estonian, you can assume we have already reduced that statement by 30% for modesty.

The post How we built the best wallet verification tool appeared first on CryptoSwift.

The post The Business Case for the Travel Rule appeared first on CryptoSwift.

For organizations whose internal policies or regulatory interpretations require stricter control over sensitive data, this challenge becomes even more pronounced.

That is the problem CryptoSwift Outpost is designed to solve.

CryptoSwift Outpost is a single-tenant, on-premises edge service that can be deployed when institutions need to keep Travel Rule PII within their own infrastructure, while still using the CryptoSwift platform for core transaction processing. In practice, that means sensitive customer data remains under your control within your environment and your SQL database, while CryptoSwift continues to power the transaction workflows around it.

The result is an operating model aligned with the needs of more stringent environments: strong data control, clear deployment boundaries, and a significantly simpler system to maintain compared to heavyweight alternatives often associated with on-premise requirements.

Why this matters for regulated entities

For many institutions, “cloud-enabled” is acceptable, but “cloud-only for sensitive PII” is not.

Travel Rule data sits in one of the most sensitive categories of operational data. It includes personally identifiable information about originators and beneficiaries, and it often falls under overlapping internal security policies, data residency requirements, outsourcing controls, audit expectations, and legal review. Even where cloud use is permitted, regulated teams still want the most defensible answer to a simple question: Where does the sensitive data live?

With Outpost, the answer is straightforward: the Travel Rule PII datastore lives on-premises, inside your environment, under your control.

That matters because it changes the conversation with risk, compliance, security, and internal audit. Instead of asking them to accept a fully outsourced storage model for sensitive data, you can present a controlled architecture where:

• Outpost runs inside your infrastructure
• the SQL database storing Travel Rule PII runs inside your infrastructure
• the deployment is single-tenant
• CryptoSwift handles core transaction processing, while your local environment remains the holder of the sensitive Travel Rule record

For regulated institutions, that is a meaningful architectural distinction.

How Outpost works

Outpost sits between your internal systems and the CryptoSwift cloud API.

Your systems integrate with Outpost as their edge endpoint. Outpost then proxies most traffic upstream, but it handles Travel Rule PII differently: it stores that data locally and links it to the corresponding transaction.

CryptoSwift Outpost: PII data remains on-premises, while 

Outgoing transactions

When your system submits an outgoing transaction through Outpost:

1. Outpost receives the full transaction payload.
2. It stores the originator and beneficiary data locally in your SQL database.
3. It forwards the transaction to the CryptoSwift cloud API for transaction processing.
4. When the cloud API returns the transaction identifier, Outpost links the local PII record to that transaction.
5. If the upstream request fails, Outpost does not silently lose the local state. It marks the record as failed and preserves the operational trail.

That last point is important. In many integrations, error handling around sensitive side data becomes an afterthought. Outpost is designed to keep a durable local record and explicit status transitions, rather than relying on brittle happy-path assumptions.

Incoming PII forwarding

For incoming Travel Rule data, the flow works in the opposite direction:

1. CryptoSwift forwards the incoming PII payload to Outpost.
2. Outpost verifies the request signature before trusting the payload.
3. The PII is stored locally in your SQL database.
4. Outpost returns the corresponding transaction identifier.

This gives institutions a consistent model for both outbound and inbound Travel Rule data: local persistence, controlled linkage, and auditable handling.

Transaction retrieval and enrichment

Outpost also solves a practical usability problem.

When a client requests a transaction by ID, Outpost first fetches the transaction from the CryptoSwift cloud API. If there is a matching local PII record, Outpost injects the locally stored originator and beneficiary data into the response before returning it.

So users and internal systems can still work with a complete transaction view, while the sensitive data remains managed locally. The cloud platform can do what it is good at, and your on-prem environment remains the source of truth for Travel Rule PII.

What makes Outpost different

Many on-prem solutions for regulated workloads become difficult not because the idea is wrong, but because the architecture is too large, too distributed, or too customized to operate cleanly over time.

Outpost takes a different approach: it is intentionally small.

At its core, the deployment model is simple:

• one single-tenant service
• one SQL database
• one clear upstream integration with the CryptoSwift cloud API
• containerized delivery via Docker
• environment-based runtime configuration
• a standard health endpoint for monitoring and orchestration

That simplicity is not cosmetic. It is the reason Outpost is easier to maintain than many comparable on-prem offerings.

There is no sprawling control plane to own. No large cluster of bespoke infrastructure components. No need to re-create an entire SaaS platform inside your environment just to satisfy a PII storage requirement.

Instead, Outpost concentrates on one job: acting as the controlled local edge for sensitive Travel Rule data.

Architecturally, it is also cleanly separated. Proxying, PII storage, transaction enrichment, configuration, logging, and persistence are split into focused components. Storage sits behind a repository abstraction, which means changes to the underlying persistence model can be made without reworking the entire service, allowing for a wide range of different database engines to be used with Outpost. Regulated deployments do not just need to launch; they need to stay supportable.

Security by design, not by marketing language

Security claims only matter when they are reflected in the way the service actually behaves.

Outpost includes several concrete controls that are especially relevant in regulated environments.

Signed incoming PII forwarding

Incoming PII forwarding is authenticated with HMAC-SHA256 using a dedicated shared secret. Outpost verifies the signature over the exact raw request body, not a re-serialized approximation. It also enforces a timestamp tolerance window to reduce replay risk and uses timing-safe comparison for signature validation.

That gives institutions a clear, defensible control around cloud-to-on-prem PII forwarding.

Controlled deployment boundary

Outpost is single-tenant and deployed inside the client environment. That reduces multi-tenant exposure concerns and gives infrastructure, security, and audit teams a much cleaner deployment story.

Hardened edge behavior

The service uses standard HTTP hardening, validates runtime configuration at startup, supports trusted reverse-proxy deployment, and exposes a straightforward health endpoint for monitoring and operational checks.

Operational traceability

Outpost does not treat failures as invisible side effects. It keeps explicit local record states, including pending, linked, stored, and upstream-failed conditions. For regulated operations teams, that improves observability and incident handling.

Why banks should care

Banks do not need another “flexible platform” that quietly pushes sensitive data governance into the implementation phase.

They need infrastructure that aligns with how regulated technology decisions are actually made:

• keep sensitive customer data under institutional control
• minimize architectural sprawl
• make security controls explicit
• preserve operational auditability
• reduce the maintenance burden on internal engineering and infrastructure teams

That is where Outpost fits.

It gives regulated institutions a pragmatic middle path. You do not have to choose between a cloud-only model for sensitive Travel Rule data and a large, expensive, custom on-prem build. You can keep the sensitive PII record on-prem, keep the deployment model simple, and still benefit from CryptoSwift’s cloud transaction processing.

The practical value of a smaller architecture

In highly regulated environments, maintainability is not a convenience issue. It is a risk issue.

Every additional moving part increases the cost of patching, validating, monitoring, documenting, and defending the deployment internally. Every custom subsystem becomes another item for architecture review, another operational dependency, another audit question.

Outpost avoids that trap by staying focused.

It is lightweight enough to operate cleanly, structured enough to evolve safely, and opinionated enough to solve the actual regulated-data problem without dragging institutions into unnecessary platform ownership.

For teams that need on-prem control without on-prem complexity, that difference is significant.

Conclusion

CryptoSwift Outpost is built for institutions that need a serious answer to PII control.

It keeps Travel Rule PII anchored on-prem in the client’s own environment, while preserving integration with CryptoSwift for core transaction processing. It provides a secure, auditable, single-tenant deployment model. And because its architecture is intentionally narrow and lightweight, it is materially easier to maintain than many traditional on-prem solutions.

For banks and other highly regulated entities, that combination is the point: stronger control over sensitive data, without inheriting a harder platform to run.

The post CryptoSwift Outpost: On-Prem Travel Rule Infrastructure for Banks and Regulated Institutions appeared first on CryptoSwift.

Each of these improvements adds valuable signals for compliance teams operating under the Crypto Travel Rule and regulations like FATF Recommendation #16 and the EU Transfer of Funds Regulation under MiCA.

But while building these features, one thing became increasingly obvious: all of them generate signals.

• Risk scores.
• VASP information.
• AML monitoring results.
• Travel Rule message statuses.

Signals are useful, but they don’t solve the operational problem by themselves. Compliance teams still have to answer the same question over and over again:

What should happen with this transaction?

• Should it proceed immediately?
• Should it be reviewed?
• Should we wait for additional confirmation?
• Or should the transaction be blocked entirely?

This is the problem the CryptoSwift Rule Engine was built to solve.

Travel Rule Compliance Is Ultimately a Decision Problem

Many Travel Rule solutions focus on one core capability: securely sending required data between Virtual Asset Service Providers (VASPs). That messaging layer is essential for compliance, but in real-world operations it’s only the first step.

Once a Travel Rule message is sent or received, platforms still need to evaluate several factors before deciding how to proceed.

Typical questions compliance teams ask include:

• Is the counterparty VASP known and regulated?
• What is their risk profile?
• What does the AML monitoring system say about the wallet address?
• Should we allow this transaction to proceed automatically?

Without a structured framework, these decisions often end up buried in application code or scattered across multiple systems.

The Rule Engine introduces a cleaner approach.

Why Compliance Logic Should Not Live in Backend Code

When crypto platforms first implement the Travel Rule, the compliance logic typically ends up hardcoded in backend services. Developers create simple conditional checks that determine whether transactions proceed or require manual review.

It usually starts with rules like:

• Allow transactions from low-risk counterparties
• Send medium-risk transactions for manual review
• Block high-risk counterparties

At first, this seems perfectly reasonable. But compliance policies rarely stay static.

Regulations evolve, risk thresholds change, internal policies adapt as teams gain operational experience.

When compliance logic lives in code, even small policy changes require developer involvement, deployments, and testing cycles. That slows down compliance teams and introduces unnecessary operational friction.

The CryptoSwift Rule Engine separates transaction signals from transaction decisions, allowing compliance teams to manage policies directly without relying on engineering changes.

A Rule Engine Designed for Travel Rule Workflows

The CryptoSwift Rule Engine acts as a decision layer on top of the data already available within the platform.

When a Travel Rule message is created, CryptoSwift may already know several things about the transaction and the counterparty involved.

For example:

• the counterparty VASP and their regulative status
• the Travel Rule risk score
• AML risk signals from wallet monitoring
• transaction attributes such as amount
• the current Travel Rule message status (was it delivered, confirmed or declined?)

Instead of forcing developers to manually combine these inputs, the Rule Engine evaluates them automatically and determines what should happen next.

Possible outcomes include:

• Proceed with the transaction automatically
• Pause the workflow and wait for a counterparty response
• Escalate the transaction for manual compliance review
• Block the transaction entirely

The result is a clear and auditable decision process that compliance teams can configure directly in the CryptoSwift dashboard.

Supporting Both Pre-Transaction and Post-Transaction Travel Rule Flows

Crypto platforms typically implement the Travel Rule using one of two models.

Post-Transaction Workflow

In this model, the blockchain transaction is executed first and the Travel Rule message is sent afterward. This is often the fastest way to become Travel Rule compliant because it requires minimal changes to existing withdrawal flows.

Many platforms start with this approach.

Pre-Transaction Workflow

In a pre-transaction Travel Rule workflow, the Travel Rule message is created before the blockchain transaction is broadcast.

This allows the platform to evaluate compliance signals first, including:

• counterparty VASP identification
• Travel Rule risk score
• AML monitoring results
• internal compliance policies

The Rule Engine then determines whether the transaction should proceed or require additional checks.

For many platforms, this enables significantly more automation and control.

Connecting the Entire Compliance Stack

One of our design goals at CryptoSwift has always been to eliminate fragmentation in compliance tooling. Crypto platforms often end up using multiple systems for different parts of the compliance process:

• a Travel Rule messaging provider
• a separate VASP identification database
• AML monitoring tools
• manual review workflows

These systems rarely communicate with each other in a structured way.

The CryptoSwift Rule Engine connects these signals into a single decision framework. Risk scores, VASP directory data, AML monitoring results, and Travel Rule message information can now all feed into the same policy evaluation process.

This approach simplifies operations and produces cleaner audit trails. When a transaction is blocked or escalated for review, the rule that triggered the decision is recorded alongside the transaction history. For compliance teams and regulators, that transparency is extremely valuable.

Automation Without Losing Compliance Oversight

Automation in compliance systems always raises an understandable concern: what happens when the system makes the wrong decision?

The Rule Engine is designed so automation can be introduced gradually. Some rules can allow low-risk transactions to proceed automatically, while others route transactions to manual review or pause workflows until additional information becomes available.

The goal isn’t to remove human oversight, the goal is to remove unnecessary manual work.

Most transactions are routine and predictable. Those shouldn’t require compliance officers to manually evaluate every detail. Automation allows teams to focus their attention where it actually matters.

From Travel Rule Messaging to Travel Rule Automation

The more we work in this space, the clearer it becomes that Travel Rule compliance is not just a messaging problem.

It’s a decision problem.

Who is the counterparty?
What is their risk profile?
Should the transaction proceed, wait, or be blocked?

The CryptoSwift Rule Engine turns the growing amount of Travel Rule data into clear operational decisions that platforms can automate and audit.

Available Now in the CryptoSwift Platform

The Rule Engine is now available in the CryptoSwift Client Dashboard and fully integrated with the CryptoSwift API and Travel Rule workflows.

If you’re already using CryptoSwift, you can start defining rules today. If you’re currently designing your Travel Rule implementation, our updated Developer Portal explains how to structure both pre-transaction and post-transaction workflows using the Rule Engine.

Our goal remains the same as always:

• less friction for developers
• more control for compliance teams
• more automation where it actually helps

And we’re just getting started.

The post Introducing the CryptoSwift Rule Engine: Automating Travel Rule Compliance Decisions appeared first on CryptoSwift.

We’ve shipped a lot. Enough that I had to think twice about whether this should be one blog post or three. But I’ll try to keep it structured and readable.

As always, we build for one reason only: to make CryptoSwift the best and easiest-to-use Travel Rule solution on the market. The one that works when compliance teams and developers need it to.

Let’s start with the biggest one.

Travel Rule Risk Score – Real-Time Risk Intelligence

We’ve added a risk score to every incoming and outgoing Travel Rule message. This might sound like a small feature, but it isn’t.

From now on, every Travel Rule message created in CryptoSwift is enriched with a transaction risk score calculated using the AML/KYT providers we already trust internally for VASP and wallet address scoring.

The logic is straightforward:

• For incoming transactions, we calculate the risk based on the originator VASP.
• For outgoing transactions, we use the beneficiary VASP risk score.
• If the beneficiary VASP cannot be immediately identified, we fall back to the destination wallet risk score.

No guessing or black magic, just structured risk assessment based on real data.

For outgoing transactions, the risk score and severity are returned immediately when the Travel Rule message is created. This makes pre-transaction flows much more powerful.

If you send the Travel Rule message before broadcasting the on-chain transaction, you can now decide:

• Do we proceed?
• Do we mark this for manual review?
• Do we stop it completely?

All before funds move.

If you operate in a post-transaction model, the risk score still gives AML officers structured data to assess customer behaviour and keep proper audit trails. It also allows for automation, because no one wants a compliance team manually checking everything in 2026.

For incoming transactions, the risk score is also included in the Travel Rule payload itself. That means you can automate deposit release flows. Low risk? Auto-credit. Higher risk? Escalate. Very high risk? Block and investigate.

The risk score is available via API and inside the Client Dashboard.

The VASP Directory

Compliance teams are constantly interested in the same questions:

Who is this counterparty?
Are they regulated?
What jurisdictions do they operate in?
What’s their risk profile?

To address these questions, we built a proper VASP Directory inside CryptoSwift. It currently contains data on over 12,000 crypto service providers globally. For each VASP, you can see:

• Risk score
• MiCA compliance status
• Countries of registration
• Contact information
• Whether they are part of the CryptoSwift network

But the important part is not the list itself. The directory is deeply integrated with the rest of our platform. When you send or receive a Travel Rule message, originator and beneficiary VASPs are automatically linked. Risk scores connect directly and everything is cross-referenced.

AML Checks

On top of the Travel Rule risk score, we added full AML checks for wallet addresses and transactions inside the Client Dashboard.

You can bring your own AML provider API key if you already have a contract. Or you can obtain an AML package via CryptoSwift.

Right now, we’re integrated with Scorechain. More providers are being added based on customer demand. If your compliance team prefers a specific vendor, tell us. We’ll integrate it.

The goal is simple: eliminate fragmentation.

You shouldn’t need one system for Travel Rule, another for wallet checks, and a third for VASP data. Everything should work together. In CryptoSwift, it now does.

AML checks link directly with Travel Rule messages and the VASP directory. That means less copy-paste, fewer context switches, and cleaner audit trails.

Wallet Verification – More Flexible & Practical

We’ve also significantly improved our self-hosted wallet verification widget and API.

This includes support for video files in visual proof flows (yes, sometimes pictures aren’t enough), more customization options, on-chain testing capabilities, and improved multi-chain support.

We strongly believe this is currently the most flexible and developer-friendly self-hosted wallet verification solution on the market.

Dashboard Improvements

We’ve continued polishing the Client Dashboard. Clearer layouts, better visibility of transaction risk, improved workflows.

Compliance is already complex, the interface shouldn’t add friction.

Small UX improvements compound over time. Fewer clicks, clearer risk indicators, faster reviews.

Developer Portal 2.0

We also completely revamped our Developer Portal:

https://dev.cryptoswift.eu

It’s no longer just technical API documentation. It now includes structured compliance workflow descriptions that help you design Travel Rule flows correctly from day one.

Because the hardest part of Travel Rule implementation isn’t the API call. It’s understanding how to structure compliant flows without ruining user experience.

We’ve documented those patterns clearly so teams don’t have to reinvent them.

Better Partner Support

Finally, we improved documentation and guides specifically for our partners: compliance companies reselling our infrastructure and other Travel Rule networks integrating with us.

Clearer onboarding, better API documentation, faster integrations: we want our partners to succeed.

Why So Much at Once?

We’ve been heads down building and prefer shipping working features over announcing roadmaps.

Everything described here has one objective: to make CryptoSwift the best and easiest-to-use Travel Rule infrastructure provider in the market.

➜ Less friction for developers.
➜ More control for compliance officers.
➜ More automation everywhere.

We’re not slowing down.

The post We’ve Been Busy Building again appeared first on CryptoSwift.