The Vision

Januar is a crypto-native Payment Institution licensed by the Danish Financial Supervisory Authority. Holding both a Payment Institution license under PSD2 and a CASP license under MiCA, Januar is passported to operate across the European Economic Area and provides regulated financial infrastructure to digital asset businesses, including IBAN accounts, payments, wallets, custody, trading, and API-based workflows.

Through its sub-custodial model, Januar enables CASPs to process stablecoin flows using regulated infrastructure while preserving their direct customer relationships. The model gives CASPs access to payment, custody, and compliance capabilities without requiring every company to recreate the same regulated infrastructure from scratch.

The Challenge: Navigating the Transfer of Funds Regulation and Subcustodial Complexities

Stablecoins are on the rise. Traders use them for instant and low-cost conversions, people use them to remit payments, businesses use them to settle invoices, and AI agents do so to do whatever AI agents do. Stablecoin payments are tantamount to traditional ones, so they are regulated accordingly. A growing number of businesses – from crypto companies to brick and mortar ones – are therefore looking for compliant stablecoin service providers. Enter Januar.

As a dual-licensed payment service provider, Januar has spent years in building a compliant financial service. Headquartered in Denmark, this has required absorbing regulatory and technological complexities in a space that is under notable public scrutiny. Understanding, and ensuring compliance with, the alphabet soup comprising MiCA, GDPR, DORA, and TFR has been a character building opportunity like no other. 

Subject to the Transfer of Funds Regulation (TFR), Januar found themselves in need of a scalable Travel Rule solution to maintain compliance. However, finding the right fit proved difficult due to several industry roadblocks:

• The “Fiat-First” Friction: Januar found that most existing Travel Rule solutions felt overpriced and notoriously difficult to implement, backed up by poor feedback from their industry peers.
• Building Reliable Travel Rule Data Flows: To support compliant deposit flows at scale, Januar needed a Travel Rule solution that could help manage incomplete incoming data, request missing information from originating VASPs, and support clear audit trails. 
• Strict Vendor Requirements: Given Januar’s subcustodial model and the fact that Travel Rule is a Critical or Important Function under the Digital Operational Resilience Act (DORA), the vendor for this role would have to strictly comply with DORA.

The Selection: Why Januar Chose CryptoSwift

CryptoSwift stood out from the competition for three main reasons:

• A Crypto-Native Approach: CryptoSwift presented itself as a reliable vendor that didn’t attempt to impose an outdated, fiat-inspired version of the Travel Rule onto modern cryptocurrency payments.
• Operational Ease: CryptoSwift’s pragmatic, well-documented, API-first product made it a clear winner. Januar recognized that this architecture would be highly reasonable to operationalize across their engineering, compliance, and customer support teams.
• European Alignment: As an EU-native company, CryptoSwift was perfectly positioned to not only help Januar comply with DORA but also to prioritize and rapidly respond to European regulatory changes like MiCAR and PSR/PSD3.

The Solution: Quick Implementation and Custom Workflows

Once selected, the deployment proved that CryptoSwift could deliver on its promises:

• Seamless Integration: Integrating with CryptoSwift’s cloud app was a remarkably smooth process – “as straightforward as it gets.”
• Data Completeness: To solve the missing deposit data issue and comply with TFR requirements, CryptoSwift quickly added a feature allowing Januar to request missing data directly from counterparty VASPs.
• Routing Support: Acknowledging Januar’s unique role in the European stablecoin transfers ecosystem, CryptoSwift quickly responded to support routing workflows, specifically catering to situations where Januar serves as an intermediary CASP.

The Result

By partnering with an EU-native, developer-friendly compliance platform like Cryptoswift, Januar successfully bridged the MiCA-PSD2 gap. Today, they continue to provide well-functioning and compliant stablecoin processing for CASPs across Europe.

The post How Januar and CryptoSwift Help CASPs Process Stablecoins appeared first on CryptoSwift.

We hear it all the time: “Crypto is the future of payments.” But despite the hype surrounding stablecoins, widespread corporate adoption remains an uphill battle. What does it actually take for digital currencies to transition from a niche, crypto-native use case to a reliable payment for B2B payments?

To explore this, our COO and Co-founder, Uve Poom, recently joined a webinar hosted by Hipther.com. Moderated by Silvia-Kairet Põld (CMO of the Estonian Web3 Chamber), the panel also featured Evald Hannes Kree, Founder and CEO of Swapin.

Here are the key takeaways on where crypto payments stand today, the compliance hurdles holding them back, and what the future holds for global adoption.

Where Are Crypto Payments Actually Being Used?

If you live in Europe, the need for crypto payments might not be immediately obvious.

“In Europe, we have the Eurozone and we have SEPA payments; money moves in most cases in under 10 seconds. For real-world payments across borders in Europe, we honestly don’t need stablecoins,” explained Uve Poom.

However, the real business adoption is currently driven by two distinct sectors:

1. Cross-Border Trade in Developing Markets: Hannes noted that the primary driver for stablecoin adoption is friction in traditional banking. “If you take third countries like Latam or Africa, and they want to trade with the Middle East, the key role will be for stablecoin use cases.” He shared an example of European merchants selling to Argentina: traditional banking requires government layers, takes weeks, and incurs high fees. Stablecoins settle the same cross-border invoice in three minutes at a fraction of the cost.
2. Institutional Trading & Asset Management: Uve highlighted a growing trend among asset managers and large financial institutions. They are increasingly adopting stablecoin infrastructure to facilitate the 24/7 trading and instant settlement of digitized securities, such as tokenized stocks and bills.

The Barrier to Entry: The “Custodial” Confusion

If stablecoins are so efficient, why aren’t more traditional merchants using them? According to the panel, a significant barrier is simply a lack of understanding regarding how to interact with the technology.

Many traditional businesses are afraid to touch stablecoins because they believe they must set up complex, self-custodial Web3 wallets. Uve pointed out that “a lot of merchants fail to understand that solutions like Swapin specifically allow avoiding setting up these custodial wallets and only receiving fiat to their traditional bank accounts.”

When businesses realize they can offer clients the option to pay in crypto while the business itself only ever touches and receives Fiat currency, adoption becomes significantly more attractive.

The Compliance Catalyst: The Travel Rule

You cannot discuss institutional crypto payments without discussing compliance—specifically, the Travel Rule.

While often viewed as a regulatory burden by crypto-native users, Uve argued that the Travel Rule is actually a massive enabler for corporate adoption.

“The obligation is to share the payment metadata between the servicing institutions,” Uve explained. Traditional fiat payments have included payer names, payee names, and invoice numbers for decades. Without this data, accountants and auditors struggle to reconcile stablecoin payments on corporate balance sheets.

“If you suddenly don’t have [this metadata] for stablecoin payments, then accountants and auditors are really struggling with matching and reconciling,” Uve noted. By implementing the Travel Rule, networks like CryptoSwift are finally providing the necessary metadata to make stablecoin payments viable for corporate accounting.

What is the Biggest Hurdle Left?

When asked what the single biggest barrier preventing wider adoption is today, the panelists had two distinct answers:

• User Experience (UX): Hannes pointed out that for the majority of the world, crypto is still entirely new. Even with simplified platforms, the underlying concepts require significant education for traditional businesses. Furthermore, corporate treasury management is difficult on standard Web3 wallets, as sharing a single seed phrase among 20 finance team members is a massive security risk.
• The €1,000 Threshold Limit: From a regulatory perspective, Uve highlighted a specific European bottleneck. Currently, transfers from regulated custodial wallets to third-party, self-custodial wallets are strictly limited for transactions over €1,000. Regulators view unhosted wallets similarly to cash transactions – highly susceptible to money laundering. This restriction could be lifted once self-hosted wallets can be properly KYCd, which is entirely possible with EU Digital Identity wallets. More specifically, digital identity wallets support keybinding – cryptographically connecting KYC data with un-hosted wallet verification credentials performed on the same device.

Looking Ahead

The consensus is clear: the underlying technology for global crypto payments is getting there. The next couple of years will be defined by an intense transitional period as the industry implements the necessary compliance orchestration layers.

As Uve summarized, “Something that was maybe only affordable to banks 10 years ago now can be affordable to an up-and-coming payment institution or fintech. I wouldn’t be afraid of these regulations once the companies operate at a sufficient scale.”

To learn more about how CryptoSwift is building the infrastructure for compliant crypto payments, explore our Travel Rule solutions today.

The post Crypto in B2B Payments: Compliance and Adoption appeared first on CryptoSwift.

The VI3NNA Declaration for 2026 was published this week. Summarizing the high-level, behind-closed-doors digital asset policy discussions from the inaugural VI3NNA Congress, the document lays out a blueprint for Europe’s regulatory and infrastructure prospects under MiCA.

While the report covers extensive ground across liquidity, taxation, and market structures, two specific recommendations regarding the Travel Rule and KYC/KYB compliance caught our eye. They call for direct feedback from the trenches—and as infrastructure providers navigating these frameworks daily, we have some thoughts.

Recommendation #1: A Single EU Onboarding and Reporting Portal

The Proposal: Build a single EU onboarding and reporting portal. The EU should develop one portal where CASPs perform KYC/AML, submit Travel-Rule data and file DAC8 tax reports, linked to eIDAS 2.0 / EUDI wallets. This is a compliance layer and shared infrastructure — explicitly not a single Level-0 settlement infrastructure “to chain them all,” and not a new regulatory tier. A practitioners’ note applies: a portal spanning KYC/AML, DAC8 reporting and MiCAR authorisation will involve multiple authorities with different mandates — financial supervisors, financial intelligence units and tax administrations. Governance arrangements must therefore assign clear ownership, delineate data-access rights between authorities and include strong data-protection safeguards from the outset. The European Commission, ESMA/EBA and AMLA should jointly design these arrangements as part of the portal’s technical specification, before deployment rather than after.

A Centralized Wolf in Web3 Clothing?

At first glance, this proposal reads like asking for a state-owned compliance vendor. Proposing a government-managed, singular system to handle KYC/AML verification for market participants across the entire Union would be remarkably… centralised. It is certainly not in the bingo card for proposals coming from a dedicated Web3 policy forum.

This setup feels fundamentally antithetical to the core tenets of decentralized architecture, European privacy considerations, and the basic principles of a free-market economy – where the state typically only steps in as a direct service provider within highly strategic domains, or where the market simply fails.

Putting Privacy at the Core: eIDAS 2.0 and EUDI Wallets

However, if you look past the initial shock value, the explicit integration with EUDI wallets (standing for European Union Digital Identity) provides ground for careful optimism.

If this portal’s underlying architecture is predicated on user-managed, privately provided digital identity infrastructure rather than a state-run honey pot of incredibly sensitive payments data, the narrative shifts. Most Payment Service Providers (PSPs) and CASPs haven’t fully understood this yet, but user authentication in Europe is due for a massive overhaul over the next five years via eIDAS 2.0. This is a rare area where decentralisation and the EU’s strict approach to data protection might actually align – provided the Union-wide compliance layer is engineered with privacy-by-design at its core.

A Better Precedent: Look to Traditional Finance

As for using a single pan-European portal exclusively for Travel Rule data exchange? While technically achievable and practically effective, the current global adoption rate of digital currency payments simply does not yet merit dedicating notable resources to a centralised message exchange layer.

Regardless, we should look to a well-functioning precedent already active in traditional European banking. Under SEPA, instant payments execute smoothly across borders utilizing the Verification of Payee (VOP) mandate. This verification is performed against the Directory Service maintained by the European Payments Council (EPC). If Europe eventually requires a unified payment data validation layer as the digital asset market matures, the EPC is already uniquely positioned to absorb and execute this function.

Recommendation #2: Mandating a Common Standard for Travel Rule Interoperability

The Proposal: Travel-Rule messages today go unanswered because neither providers nor their regulators require interoperability across networks. The EU should mandate common data-exchange standards (e.g. TRISA, IVMS 101) so transfers can be individually identified across providers; the cross-border payments use case is the real opportunity being lost.

The Reality: It’s Not a Tech Problem, It’s a Trust Problem

While this recommendation is far less controversial than a centralized onboarding hub, it is also unfortunately far less effectual.

The data exchange bottlenecks occurring between various Travel Rule providers today are not stuck behind a missing technical standard or an uninvented protocol. The industry already possesses the necessary standards. The real friction comes down to a basic lack of management will.

At CryptoSwift, we have always maintained an open ecosystem stance regarding interoperability. Our orchestration layer routinely integrates with peer compliance systems running on different protocols. These connections don’t happen when a data exchange standard is decreed; they happen when two Travel Rule service providers decide to build the bridge.

When will the rest of the industry follow suit? When supervisors and national regulators actively step up the enforcement of the Travel Rule across the board. They just haven’t gotten around to it yet.

The Path Forward

We owe a round of applause to Oliver Schmitt and his team at the VI3NNA Congress for facilitating these critical, high-stakes policy debates. Shaping European regulations that simultaneously protect users while fostering a thriving digital asset ecosystem is an incredibly delicate balancing act, and bringing these discussions into the open is exactly what market participants need.

The post Behind Closed Doors: A Breakdown of the VI3NNA Declaration appeared first on CryptoSwift.

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.