Compliance

Built to keep digital assets inside the perimeter you already operate in.

Banks do not fear digital assets. They fear new, uncontrolled obligations, activity that lands outside the supervisory framework they already answer for. Suave is built so that going on-chain does not create any.

You keep your customers, your records, your reporting lines, and your examiner relationships. Suave is the connective layer underneath, designed to feed the controls you already run rather than stand up a second set beside them. The bank is still the principal. The program is still yours.

One framing before anything else. Where this page names a regime, it means the framework the system is architected around, and the controls it gives your team to meet it. The institution remains the regulated party; Suave equips the program, it does not replace it.

The regulated perimeter is the product

Most digital-asset vendors ask an institution to adopt something new (a new chain, a new wallet model, a new custodian, a new counterparty network) and then bolt compliance features to the side. That inverts the bank's actual problem. The bank's obligation is continuous and personal: the BSA program is the bank's, the OFAC exposure is the bank's, the audit trail an examiner reviews is the bank's.

Suave starts from the obligation, not the feature. The design goal is that on-chain activity produces the same evidence, in the same systems, against the same controls as the rest of the bank's book, so that “we moved into digital assets” and “we stayed inside our supervisory framework” describe one decision, not two.

Because Suave operates no chain or network of its own, there is nothing for your activity to migrate onto, and therefore no perimeter for it to leave.

Identity: CIP, KYC, KYB, CDD, EDD, and beneficial ownership

The bank runs onboarding and identity on its own program. Suave is built to support that program where digital-asset activity touches it, not to operate a second one alongside it.

CIP: Customer Identification Program at account openingDesigned to attach wallet and on-chain identifiers to the bank's existing customer record, not a separate identity store
KYC / KYB: Individual and business customer due diligenceBuilt to feed the bank's KYC/KYB workflow; the bank's risk rating and decisioning stay authoritative
CDD: Ongoing customer due diligence and risk scoringDesigned so on-chain behavior is an input to the bank's CDD, not a parallel score the bank cannot see
EDD: Enhanced due diligence for higher-risk relationshipsSupports the escalation paths the bank already defines
UBO: Beneficial ownership under the FinCEN CDD ruleArchitected around the 25% ownership threshold and the control-person prong; ownership data maps to the bank's existing UBO records

The bank remains the principal performing diligence. Suave's role is to make on-chain identifiers legible to the controls the bank already runs.

AML monitoring: BSA program, KYT, and SAR-ready data

On-chain monitoring is not a separate discipline from the BSA/AML program. It is the same discipline applied to a transaction graph instead of a wire. Suave is built to bring Know Your Transaction (KYT) monitoring into that program.

Typology-aware monitoring. Designed to surface the patterns examiners expect a program to detect (structuring, layering, peel chains, rapid in-and-out movement, exposure to high-risk services) as alerts that route into the bank's existing case management, not a separate console no one reconciles.
SAR-ready data, not SAR filing. Suave does not file Suspicious Activity Reports, and will not on the bank's behalf. What it is built to do is preserve the underlying transaction detail, the on-chain trace, and the alert rationale in exportable form, so that when the bank's analysts decide a SAR is warranted (the FinCEN threshold is generally around $5,000 where a suspect can be identified), the supporting record is already assembled.
CTR support. Designed to carry the value and counterparty detail the bank needs for Currency Transaction Report obligations where they apply.

The decision to file, and the filing itself, stay with the bank. Suave is built to make the evidence behind that decision complete.

Sanctions: OFAC screening and on-chain analytics

Sanctions screening for digital assets fails in a specific way: name-matching a customer against the OFAC SDN list is necessary but not sufficient, because a clean counterparty can sit one or two hops from a sanctioned address. Suave is architected around both halves of the problem.

List screening. Designed to screen customers and counterparties against the OFAC SDN List and the OFAC Consolidated Sanctions List, alongside wallet-address screening, because the sanctioned entity may be an address, not a name.
Direct and indirect exposure. Built to support transaction-graph analysis, not only direct hits. Indirect exposure, funds that reached a wallet through a sanctioned intermediary, is where address-only screening misses, and where examiners now look.
Mixer and obfuscation exposure. Architected to flag exposure to mixing services and sanctioned protocols. The Tornado Cash designations established that code itself can carry sanctions consequence; exposure is measured at the protocol level, not only the named-person level.
Analytics integration. Banks expect digital-asset monitoring to work with the providers they already trust. Suave is built to integrate with Chainalysis, Elliptic, and TRM Labs rather than to replace them; the bank keeps its chosen analytics vendor and its existing risk thresholds, and Suave connects to them.

The bank sets the risk appetite and the block, hold, or escalate decision. Suave is the plumbing that makes direct and indirect exposure visible to that decision.

The FATF Travel Rule

The Travel Rule (FATF Recommendation 16) requires originator and beneficiary information to travel with a qualifying transfer. Suave is architected around it.

Designed to capture and transmit the required originator and beneficiary data for covered transfers.
Built to apply the relevant thresholds (the FATF baseline of roughly USD/EUR 1,000 and the US BSA recordkeeping threshold of $3,000) to the bank's own configuration rather than imposing one.
Positioned to work with the messaging and counterparty-discovery arrangements an institution already uses, so Travel Rule compliance extends existing correspondent practice rather than adding another island.

Recordkeeping and examiner-ready audit trails

Examiners want evidence, not explanations. The defensibility of a digital-asset program rests less on any single feature than on whether the institution can show, after the fact, what it knew and when it acted.

Suave is built to produce that record:

Tamper-evident, exportable audit trails covering identity decisions, monitoring alerts, sanctions screening results, and Travel Rule transmissions.
Reconstruction on demand: the full on-chain trace behind any alert or decision, retrievable in a form an examiner or internal audit can read.
Alignment with FFIEC expectations: designed around the recordkeeping and control-evidence standards set out in the FFIEC BSA/AML Examination Manual, so the artifacts the bank produces are the artifacts an examiner asks for.

The record lives where the bank can govern it. Suave is built to fill that record completely, not to hold it.

Integration with the bank's existing stack

A compliance layer that demands rip-and-replace defeats its own purpose: every new system is a new thing to control and a new thing to explain. Suave is built to extend what the institution already runs.

Designed to deliver alerts, cases, and evidence into the bank's existing case management, transaction monitoring, and reporting systems through clean APIs.
Built around the messaging and data standards banks already operate, including ISO 20022, so on-chain events reconcile against the core rather than sit beside it.
Architected for clean reconciliation: the bank's books and the on-chain record agree, and the bank can prove it.

This is not about trading your compliance infrastructure for ours. It is about making on-chain activity legible to the infrastructure you already run.

Frameworks the system is architected around

These are the regimes the design is built to support. Suave does not claim a held license, charter, or certification under any of them. This is the frame the architecture is shaped to; the bank remains the regulated party.

Architected around

FinCEN
FATF
GENIUS Act
MiCA
NYDFS
MAS

FinCEN: BSA program, CDD/UBO rule, SAR and CTR reporting, Travel Rule recordkeeping
FATF: Recommendation 16 (Travel Rule); international AML/CFT standards
GENIUS Act: US stablecoin framework, including permitted-payment-stablecoin issuer (PPSI) requirements
MiCA: EU markets-in-crypto-assets regime, including CASP obligations
NYDFS: New York virtual-currency supervision and related expectations
MAS: Monetary Authority of Singapore digital-asset and payments regimes

Suave is built to be configurable to the regime the institution operates under, rather than assuming one jurisdiction for everyone.

What Suave does, and what stays yours

Good infrastructure is clear about the line between the vendor and the bank. Here is ours.

Suave provides: The connective layer, with controls built into the path rather than bolted to the side: identity support, on-chain transaction monitoring, OFAC and wallet screening through the analytics your team already uses, Travel Rule data, and tamper-evident, examiner-ready audit evidence, all integrated into the systems and program you already run.
You remain the regulated party: Your licenses, your charter, your customer and examiner relationships, and your risk decisions stay yours, and so do your regulatory filings. Suave equips the program and produces the evidence; the institution owns it, and owns the supervisory relationship around it.
Brought in early: The integration is shaped by your compliance, BSA/AML, and third-party-risk teams from the start. We want them in the room before anything is decided, because examiner-defensibility is a property of the whole program, and the bank owns the program.

Talk to the team that built this around your perimeter, not around our chain.

Bring your compliance and third-party-risk people. We will walk the controls line by line and show exactly how each one maps to the obligations you already carry.

Start a conversation