Choose a scenario, change its configuration, step through the customer experience, and follow the corresponding API requests, widget events and webhooks alongside it.

Our integration guides and compliance workflows still contain the implementation details. The demos are there to give you the bigger picture first.

Who has time to read documentation? Kidding. We spent quite some time writing it. But sometimes clicking through a flow is simply the fastest way to understand how all the pieces fit together.

Interactive integration demos: three panels, one connected flow

The demo page is split into three connected panels.

On the left, you choose a scenario and configure the situation you want to explore. In the middle, you go through the flow in Demo Bank, a sample application representing your own product. On the right, you can inspect the API calls, widget events and webhook notifications triggered along the way.

When a flow involves your compliance or operations team, you can switch between the customer application and a simplified admin dashboard. Both views follow the same case, letting you trace the journey from customer action to operational review and backend processing.

The sequence panel includes requests and responses with code examples you can inspect and copy. Links to the relevant guides are available when you want to go deeper into the implementation details.

The demos currently cover Smart Withdrawal, Travel Rule messaging, wallet verification and Wallet Intelligence (KYW). You can explore each building block separately or see how they connect in a complete withdrawal journey.

Change the settings and run the flow again to try a different outcome. Counterparty responses and blockchain transfers are simulated, so you can explore the experience without configuring credentials or moving funds.

See how the pieces come together

The Smart Withdrawal flow shows what these interactive integration demos are especially useful for: combining several CryptoSwift capabilities into one realistic customer journey.

Your customer wants to withdraw funds. They enter the recipient name, destination wallet, amount and asset. But what happens next depends on the wallet they are sending to.

First, CryptoSwift can run a Wallet Intelligence (KYW) check to determine whether the destination is custodial or self-hosted. If it is custodial, the flow continues with a Travel Rule message to the receiving VASP. If it is self-hosted, you can instead start self-hosted wallet verification when required by your policy or transaction threshold.

And you can take the scenario further. What if KYW cannot determine the wallet type with enough confidence? You can ask the customer for more information and continue from there. Need to identify the VASP? VASP search is available as part of the flow. What if the wallet belongs to a third party rather than the customer? You can explore that path too.

The point is not to prescribe one withdrawal process. Different businesses have different policies, risk thresholds and customer journeys. The demo lets you explore the scenarios that are relevant to you, see the resulting API calls and events, and understand how individual CryptoSwift building blocks can be combined into one complete flow.

Good building blocks need good documentation

For us, providing an API is only part of the job. We also want to make it clear how the pieces fit together: what happens in your application, what your backend needs to handle, and where compliance or operations teams become involved.

A field description or request example is useful. So is a workflow guide. An interactive example adds another way to understand the same process, especially when several services, systems and teams are involved.

Different teams also look at the same integration from different perspectives. An engineer may want to inspect requests, responses and events. A product person may want to understand the customer journey. A compliance team may want to see where their decisions and review steps fit into the process.

The demos put those perspectives into one shared flow. It is much easier to discuss an integration when everyone can follow the same case and see how their part connects to the rest.

Even complicated things should be easy to understand

Travel Rule integrations involve several systems, people and decisions. There is enough complexity in the actual work, so understanding how everything fits together should not add more.

We believe even complicated compliance workflows can be explained clearly. That principle shapes how we build the CryptoSwift API, dashboard and developer portal. The interactive integration demos are another part of that approach, giving you a practical way to explore the flows before starting the implementation.

Choose a scenario and try the demos. Configure the flow, run through it, and inspect what happens behind the scenes.

And when you are ready to build, the documentation will still be there.

The post CryptoSwift now has interactive integration demos appeared first on CryptoSwift.

The annual CV Summit 2026 wrapped up in Zurich, bringing together market leaders, regulators, and builders to discuss the next era of digital asset policy, market structure, and compliance.

Opening the conference, Christopher Perkins (Head of Franklin Crypto at Franklin Templeton) delivered a keynote titled “Rewiring The Next Era of Finance”, framing the current paradigm shift with a sharp thesis:

“Tokenization is electronization 2.0 for finance.”

Just as the first wave of digitization converted paper ledgers into electronic records, tokenization is transforming static financial instruments into programmable, real-time assets. From the sessions in Zurich, here are the core takeaways on how market infrastructure is shifting – and what it means for the future of crypto compliance and Web3 payments.

1. Fiduciary Duty in a 24/7 World

Traditional 9-to-5 banking hours are rapidly morphing from a standard operational constraint into an obsolete risk model.

In a hyper-connected global economy, market-moving events and geopolitical shifts do not wait for Monday morning’s opening bell. Asset managers increasingly face a fundamental question: if a crisis or liquidity event unfolds over the weekend, can you react in real time, or are your assets locked behind legacy banking hours?

Operating on 24/7 digital asset rails is no longer just a technological experiment; it is evolving into a core fiduciary duty. Institutions that fail to adopt real-time, continuous settlement models will find themselves operating at a severe disadvantage when managing risk.

2. Autonomous AI Agents Require Native Stablecoin Rails

As artificial intelligence moves from simple prompts to autonomous execution, AI agents are taking over complex economic workflows.

During the summit, Christian Moser from TWINT highlighted how agentic AI will transform asset management. Autonomous agents will soon execute rapid, high-frequency investment decisions – constantly optimizing across risk, yield, and liquidity parameters. This shift will drive an exponential surge in micro-transactions and digital asset transfers.

However, legacy banking infrastructure is fundamentally unequipped for this reality. An autonomous software agent cannot walk into a bank branch, sign paper onboarding forms, or maintain a traditional bank account.

AI agents require 24/7, programmable, native financial rails – and stablecoins are the natural settlement layer for this emerging machine-to-machine economy.

3. Quantum Threat vs. Blockchain Tailwinds

The rise of quantum computing is frequently framed as an existential threat to digital security. While quantum advances do pose challenges across all legacy financial systems and encryption protocols, crypto infrastructure possesses a unique advantage: it is natively built to adapt.

Unlike legacy core banking software that takes years to patch, decentralized architecture and modern cryptographic protocols are designed for rapid, modular upgrades. Rather than an existential roadblock, the transition toward post-quantum cryptography acts as a structural tailwind for blockchain-native infrastructure.

The Road Ahead

The convergence of blockchain rails, autonomous AI agents, and post-quantum cryptography is fundamentally rewiring how global finance operates. Building the compliant, enterprise-grade plumbing to support this transformation is our focus at CryptoSwift.

The post Tokenization, AI Agents, and 24/7 Markets: Takeaways from CV Summit 2026 appeared first on CryptoSwift.

In the EU, there are two main sources to start with: the Transfer of Funds Regulation (TFR) and the European Banking Authority (EBA) Travel Rule Guidelines.

The TFR sets the legal requirements. It defines what information must accompany a crypto-asset transfer, what the originating CASP is required to send, what the beneficiary CASP is expected to detect, and how missing or incomplete information should be handled.

The EBA Guidelines take these requirements further and provide more detail on how CASPs are expected to implement them in practice, including detecting missing or incomplete information, dealing with transfers where required information is missing, and determining what action should be taken.

To build a practical audit framework, the TFR and EBA Guidelines first need to be dismantled into individual requirements that can be translated into concrete audit checks.

This means looking at the full lifecycle of a transaction: whether the transfer is in scope, whether the required originator and beneficiary information is complete and accurate, how and when that information is transmitted, how incoming transfers are matched with Travel Rule messages, and how missing or incomplete information is detected and handled. From there, the audit needs to cover self-hosted wallets, counterparty identification, screening, exception handling and decisioning, repeatedly failing counterparties, recordkeeping and, importantly, the systems and protocols used to exchange Travel Rule information.

Once the requirements are viewed this way, the audit becomes less about checking whether a Travel Rule message exists and more about whether the controls around the entire process actually work.

A very practical example comes from everyday operations. Consider a scenario where CASP A has implemented the Travel Rule requirements and transmits the required information. CASP B has done the same and has processes in place to receive and process that information.

In theory, this should result in a compliant Travel Rule flow between the two CASPs.

In practice, CASP A might be using Travel Rule Provider X while CASP B uses Provider Y. If those providers operate on different networks and there is no interoperability between them, the crypto transfer can arrive while the corresponding Travel Rule message does not.

It is therefore possible for two CASPs that have implemented their respective Travel Rule obligations to still end up with no automatically received Travel Rule message.

And this is where auditing the Travel Rule becomes more interesting than simply checking whether a message was received.

Importantly, a missing Travel Rule message does not determine the outcome on its own. It triggers a process. The beneficiary CASP needs to detect the missing information, assess the circumstances and apply its risk-based procedures to determine what happens next. The EBA Guidelines also make clear that missing information per se does not give rise to suspicion of ML/TF.

From an audit perspective, the focus therefore shifts from the missing message itself to how the CASP identifies, investigates and manages the exception:

• Can the beneficiary CASP identify the originating CASP?
• Can it determine whether Travel Rule information was required for the transfer?
• Can it reconcile the blockchain transaction with the corresponding Travel Rule message?
• If the information is missing, is there a process for requesting it from the originating CASP?
• And is there a documented, risk-based approach for deciding whether to execute, suspend, reject or return the transfer?

The important part is not simply that an exception occurred, but whether the CASP can demonstrate how it was identified, assessed and resolved.

This is also where the EBA Guidelines leave some room for interpretation. They set expectations for detecting and managing missing information, but how those requirements are translated into operational controls is ultimately left to the CASP. At the same time, they do not solve the underlying technical problem: different Travel Rule networks may still be unable to communicate with each other.

Until there is stronger interoperability between providers, different networks are pushed or required to connect to each other, or another industry-wide solution emerges, we will continue to see this gap. Today, a CASP could even connect to multiple providers, yet still face the same challenge if the underlying networks remain fragmented.

At the end of the day, having a Travel Rule solution and the right controls in place, even with connectivity to multiple Travel Rule networks, does not necessarily mean that the required information will successfully reach the intended counterparty CASP.

From an audit perspective, the real test is not whether every incoming transfer has a corresponding message, but whether the CASP can demonstrate how each exception was handled. If an incoming message is missing, can the CASP demonstrate that it was detected, what happened next, what information was requested, which risk factors were considered, and why the transfer was ultimately executed, suspended, rejected or returned?

A risk-based approach gives CASPs flexibility, but that also means that how each transfer is handled needs to be explainable, consistent and documented.

There is also a broader layer to this that goes beyond the EU framework. FATF Recommendation 16 provides the international foundation for the Travel Rule, yet jurisdictions have implemented it at different speeds and, in some cases, with different thresholds and requirements. FATF’s 2026 update shows that 83% of responding jurisdictions have passed Travel Rule legislation, meaning the regulatory environment on the other side of a transfer may look very different from the one under which the CASP operates. This raises another set of audit questions: what happens when the counterparty is subject to a different threshold, different requirements, or operates in a jurisdiction where the Travel Rule has not yet been implemented? That probably deserves an article of its own.

So perhaps the most useful question for a CASP to ask before an auditor does is: are its crypto-asset transfers actually auditable?

The post From Regulation to Audit: Dismantling the TFR and EBA Travel Rule Guidelines appeared first on CryptoSwift.

Collect Source of Funds, Source of Wealth, and liveness evidence in one connected verification journey.

Confirming control of a self-hosted wallet is often only one part of a compliance decision. Depending on the customer, transaction, and risk profile, compliance teams may also need financial evidence. In some cases, they may also need stronger assurance that a real person completed the verification.

To support this, we have added optional steps to self-hosted wallet verification. As a result, businesses can now collect liveness and financial evidence in the same customer journey as wallet ownership verification.

One journey, more complete evidence

Businesses can now add one or both of the following checks to a wallet verification:

• Source of Funds / Source of Wealth: Request supporting documents such as bank statements or other relevant evidence. In addition, businesses can include a customer-specific message that explains what the customer must provide.
• Guided Selfie: Ask the customer to complete a short guided camera flow. For example, the customer may turn their head, look up or down, or blink.

Customers complete these steps directly in the CryptoSwift Wallet Verification Widget. Therefore, they do not need to switch between separate forms or disconnected verification products.

See the full customer and reviewer journey in our Additional Steps workflow guide.

Backend liveness analysis

The Guided Selfie flow gives customers real-time instructions during the capture. However, CryptoSwift does not rely only on what the browser reports.

After the capture ends, CryptoSwift securely submits the evidence for backend liveness analysis.

The backend checks whether the customer completed the requested actions in the correct order. It also checks whether the customer returned to a neutral position between movements. In addition, it reviews the consistency of the submitted video and image evidence.

As a result, businesses get an independent backend validation layer instead of relying only on client-side capture signals.

When automatic approval is enabled, a successful backend liveness result can automatically verify the Selfie step. However, businesses can also disable automatic approval. In that case, reviewers can inspect the images, video, and analysis result in the Client Dashboard.

The liveness check validates the captured interaction. It does not match the customer’s face against an identity document.

Built for risk-based compliance

These optional steps support different risk-based approaches. As a result, businesses can apply more checks where needed without adding the same friction to every case.

A business can:

• request only wallet ownership verification for lower-risk cases
• add a Guided Selfie when it needs stronger evidence of customer presence
• request Source of Funds or Source of Wealth documents when it needs financial evidence
• combine both steps in a single verification
• automatically approve successful liveness checks or keep manual control
• review wallet ownership and each additional step as separate decisions

This gives compliance teams more flexibility. For example, they can keep the flow simple for low-risk cases and apply more controls to higher-risk ones.

A smoother experience for customers and compliance teams

For customers, the flow stays simple. They verify the wallet, complete any requested additional steps, and submit everything in one journey.

Meanwhile, compliance and operations teams receive a consolidated verification record. This record includes the wallet ownership result, the status of additional checks, submitted evidence, the liveness outcome, and the review history.

Therefore, teams can reduce fragmented evidence collection and simplify operational follow-up. In addition, they can see more clearly whether the customer completed every check required by company policy.

Available now

These optional Source of Funds / Source of Wealth and Guided Selfie steps are now available as part of CryptoSwift self-hosted wallet verification. Businesses can use them through the Client Dashboard, Wallet Verification Widget, and API.

Explore the documentation:

• Additional Steps integration guide
• Customer and reviewer workflow
• Self-hosted wallet verification overview
• Wallet Verification Widget

The post Go beyond wallet ownership with optional verification steps appeared first on CryptoSwift.

The post Travel Rule Vendor Considerations for Crypto-Asset Service Providers (CASPs) appeared first on CryptoSwift.

On June 19, 2026, Law No. 10961 was published in the official gazette La Gaceta – an amendment to the country’s core anti-money laundering statute, Law No. 7786, which for the first time introduces the concept of a VASP (Virtual Asset Service Provider) and places such companies under AML supervision. The law takes effect three months after publication – around September 19, 2026.

Here’s a full breakdown: what’s changing, who it affects, the penalties involved, and what businesses should be doing right now.

Why Now

The formal trigger is pressure from the Financial Action Task Force (FATF) (Financial Action Task Force). Back in 2024, the organization explicitly flagged a regulatory gap in Costa Rica around companies dealing in crypto assets – essentially, the risk that the country could become a convenient transit point for money laundering through crypto. The reform was tracked under Bill No. 25,340 and was ultimately approved unanimously by the Legislative Assembly in its second debate on May 25, 2026.

This fits into a broader regional trend: Panama introduced its own comprehensive VASP/CASP licensing bill to the National Assembly in January 2026 (Anteproyecto Ley No. 314), OECD countries are synchronizing CARF reporting (the international exchange of crypto tax information), and FATF continues pushing all jurisdictions to implement Recommendation 15 – the baseline standard for virtual asset regulation. Costa Rica wasn’t a first-mover here – it was closing one of the last visible gaps in its own AML framework.

What the Law Actually Changes

Law No. 10961 adds a new Article 15 quater to Law No. 7786. The core message from lawmakers: this isn’t a ban, and it isn’t legal recognition of crypto as currency – it’s bringing certain business activities into the existing AML/CFT supervisory perimeter.

Key principles to understand:

• Bitcoin does not become legal tender. The colón remains the sole official currency, and the Central Bank of Costa Rica does not recognize crypto assets as money or foreign currency.
• Crypto itself is not banned – for individuals or businesses. Private individuals remain free to hold, receive, and transfer crypto assets in private transactions.
• What changes is the status of intermediary businesses – companies that provide crypto-related services to third parties.
• The supervisor is Superintendencia General de Entidades Financieras – SUGEF (the General Superintendency of Financial Entities), while detailed implementing rules (transaction thresholds, technical requirements) are expected from Consejo Nacional de Supervisión del Sistema Financiero (Conassif) (the National Council for Financial System Supervision) within three months.

Who Qualifies as a VASP

The law’s definition is deliberately broad and doesn’t hinge on how a company brands itself – it doesn’t matter whether a project calls itself an “exchange,” a “payment gateway,” or a “fintech platform.” What matters is the activity actually performed. A company qualifies as a VASP if it performs, on a regular business basis (not as an isolated transaction):

• exchange between crypto and fiat currency, or between crypto and crypto;
• transfer of virtual assets on behalf of clients;
• custody, administration, or other forms of control over third-party virtual assets;
• financial services related to the issuance, offering, sale, or promotion of virtual assets – which also brings token projects raising funds into scope.

SUGEF Registration Is NOT a License

One point worth stressing, since it’s often misunderstood: registering as a VASP with SUGEF does not constitute authorization to operate. It is not a banking license, not a securities license, and not a general approval of a company’s products or tokens.

What registration actually means in practice:

• the company becomes visible to the AML supervisor;
• it must comply with AML/CFT obligations;
• it may face information requests, inspections, and sanctions;
• it gets entered into a centralized VASP registry.

In other words – you don’t “get a crypto license.” You determine whether your activity qualifies as a VASP, and if it does, you register and comply. The law does not set a fixed registration fee: CONASSIF will define the details, and supervision costs will be recovered proportionally to a company’s size, number of operations, and transaction volume. The real cost driver is the compliance program itself – policies, a compliance officer, monitoring tools, recordkeeping systems, legal support. That should be budgeted before launch, not after.

VASP Obligations Under the Law

A company that qualifies as a VASP must build a real AML/KYC program – not just incorporate a legal entity:

• Customer identification – using reliable and independent information.
• Beneficial ownership verification – understanding who ultimately controls a client or structure.
• Risk-based due diligence – before and during business relationships.
• Transaction recordkeeping – sufficient to reconstruct operations on request from authorities.
• PEP controls – for politically exposed persons.
• Assessment of new-technology risk – for new products, services, and business practices.
• Enhanced controls for high-risk jurisdictions.
• Suspicious transaction reporting – confidential and without delay, to the Financial Intelligence Unit at the ICD (Costa Rican Drug Institute).

One provision with outsized operational impact deserves particular attention: the Travel Rule – the requirement to attach originator and beneficiary information to virtual asset transfers, in line with FATF standards. For exchanges, custodians, OTC desks, and transfer platforms, this can mean reworking onboarding flows, data architecture, blockchain analytics, transaction monitoring systems, and user agreements.

The law also reaches trust and fiduciary structures: if a trust administers virtual assets, it falls under Article 15 quater supervision too – relevant given how heavily Costa Rica is used for escrow and fiduciary arrangements.

Penalties for Non-Compliance

The reform updates the sanctions regime under Law No. 7786 for VASPs and other obligated parties:

• Fines of 5% to 50% of the transaction amount for certain violations;
• Fines of 2 to 100 base salaries for specific compliance failures (failure to register, identify customers, keep records, etc.);
• Late-payment surcharges if a fine isn’t paid within the legal deadline;
• Publication of final sanctions by supervisory authorities;
• Supervisory powers to inspect, request information, and enforce.

International Structures and Holding Companies: Where the Line Sits

A practical question that comes up constantly: what about Costa Rican entities that are formally incorporated locally but serve clients abroad? Here, the law regulates activity, not the “nationality” of the entity.

SUGEF registration is likely NOT required if all of the following hold:

• the company doesn’t operate an exchange or platform;
• it doesn’t sign contracts directly with clients/users;
• it doesn’t provide custody, transfer, administration, or control of assets;
• it doesn’t provide financial services related to asset issuance;
• all activity, clients, infrastructure, and personnel are located outside Costa Rica;
• the company functions purely as a passive holding or investment vehicle.

Registration IS likely required if the Costa Rican entity is the one actually providing the service – signing user contracts, operating the platform, collecting fees, providing custody, or transferring assets – even if all clients are located abroad.

This is especially relevant for exchanges, OTC desks, custody and wallet providers, token issuers, Web3 startups with founders or management based in Costa Rica, and fintech companies integrating crypto payment rails.

Tax Considerations

Costa Rica generally follows a territorial tax system – a company isn’t taxed simply because it’s incorporated there. Everything depends on where income is generated, where the activity is actually carried out, where value is created, and where management decisions are made.

Lower tax exposure is more likely when:

• operations happen outside Costa Rica;
• key infrastructure is located offshore;
• management functions sit outside the country;
• real foreign economic substance can be demonstrated.

Tax risk increases when:

• services are actually performed in Costa Rica;
• operational staff are based locally;
• management decisions are made in-country;
• clients are served from Costa Rica;
• the business has local infrastructure, employees, or other economic substance.

The Banking Problem Isn’t Solved

An important caveat that’s easy to overlook: having a formal VASP framework doesn’t automatically solve the banking challenge for crypto businesses. Local banks may still be cautious due to their own risk appetite, correspondent banking concerns, and enhanced due diligence requirements. A serious crypto structure shouldn’t incorporate first and explain itself to a bank afterward – banking strategy needs to be built into the legal design from day one: ownership structure, source of funds, compliance program, client profile, and transaction flows.

Bottom Line

Costa Rica is finally shedding its “gray zone” reputation for crypto business – without becoming a fully licensed jurisdiction like the ones now requiring formal VASP authorization. What emerges is a middle-ground model: the activity is legal, registration is mandatory, but there’s still no license in the classic sense. For crypto companies operating in the region, the signal is clear: the window for running a crypto business under “default, no special rules” closes on September 19, 2026 – and anyone falling under the VASP definition has the summer to get compliant.

The post Costa Rica Brings Crypto Businesses Under AML Oversight: Breaking Down Law No. 10961 appeared first on CryptoSwift.

Financial Action Task Force (FATF) revised Recommendation 16 in June 2025 to strengthen payment transparency, improve the consistency of originator and beneficiary information, and introduce measures to prevent payments from being sent to unintended recipients.

In June 2026, FATF published draft guidance explaining how financial institutions could implement these requirements. The related public consultation closed on 21 August 2026, so the final guidance and consultation results are yet to be published.

Nevertheless, the revised Recommendation and draft guidance already highlight several practical issues that compliance and operational-risk teams should begin considering. These include more structured data, beneficiary-alignment controls and greater payment transparency.

For CASPs, the challenge is not simply to update a Travel Rule policy. It is to implement these controls without creating transaction delays, data-protection risks or operational vulnerabilities.

This is where the FATF Recommendation 16 and the EU’s DORA intersect. While DORA compliance is only mandatory for European CASPs, the principles are relevant for responsible VASPs globally.

Travel Rule compliance relies on technology that collects sensitive personal data, communicates with counterparties and may perform checks before a transaction is completed. If this technology becomes unavailable, processes data incorrectly or creates bottlenecks, the impact can go beyond compliance and disrupt the entire transaction flow.

So, what should compliance and operational-risk teams pay attention to?

1. Prepare for beneficiary-alignment controls

Under the revised Recommendation 16, beneficiary financial institutions will need to take measures to reduce the risk of payments being sent to unintended recipients.

These measures may include transaction-level checks, broader risk-based monitoring or pre-validation mechanisms involving both institutions.

Crypto service providers will need to define how these checks should be performed and what should happen when information is missing, does not match or cannot be verified in time. Although FATF does not prescribe a single technical workflow, automated rules can help process straightforward cases while sending incomplete or potentially misdirected transactions for further review.

Other than the FATF guidance, paying more attention to the verification of payees also makes sense for crypto PSPs – unlike users depositing or withdrawing funds from their exchange accounts, stablecoin payments need to replicate controls familiar from the fiat space

2. Build for data standardization

The revised Recommendation 16 moves towards more structured originator and beneficiary information, using established messaging standards such as ISO 20022 where appropriate. It also introduces more consistent information requirements and identifiers such as LEIs for legal entities, where available.

Companies should assess whether their internal systems and technology providers can adapt to these requirements and exchange information reliably across different networks and legacy systems.

3. Balance transparency with privacy

Collecting and sharing more personal information also creates greater data-protection responsibilities.

Cross-border Travel Rule messaging must take into account GDPR requirements, data minimization, secure storage and restrictions on international data transfers.

Compliance teams should understand where personal data is processed, how long it is retained, which parties can access it and what safeguards apply when it crosses borders.

4. Treat operational resilience as part of Travel Rule compliance

Under DORA, European CASPs must manage ICT risks and dependencies on third-party technology providers. This makes the reliability, security and recoverability of Travel Rule infrastructure an important part of vendor assessment.

Availability, incident response, business continuity, data integrity and information security should therefore be considered alongside regulatory functionality.

The revised Recommendation does not prescribe a single technical process. The main challenge for compliance teams will be translating its requirements into practical and proportionate controls that improve payment transparency without creating unnecessary delays or operational risks.

Sources:

• FATF: Updates to Recommendation 16 on Payment Transparency, June 2025
• FATF: Public consultation on guidance for implementing Recommendation 16, June 2026
• Regulation (EU) 2022/2554 on digital operational resilience-DORA

The post FATF Recommendation 16 meets DORA: What should compliance teams consider when preparing for implementation? appeared first on CryptoSwift.

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.