Old Tricks for New Dogs, Part IV

CARF's Reporting Obligations

By Peter A. Cotorceanu & Paul Foster Millen, 4 Nov, 2024

  This article was originally published in Tax Notes International, November 4, 2024, p. 801

All roads lead to Rome. Not literally of course. But all cryptoasset reporting framework (CARF)¹ due diligence obligations do literally lead to one destination: Reporting.

In the immediately preceding article in this series,² we covered CARF’s due diligence processes. Due diligence is, of course, a fundamental part of CARF, just as it is of the automatic exchange of information regime on which CARF was modeled (the common reporting standard,³ CRS). However, due diligence is not an end in itself; it is merely the road to CARF’s ultimate goal. That goal — “Rome” if you will — is the actual reporting on cryptoasset transactions, which is based on the information dredged up during the due diligence process.

In this, the fourth article in a series,⁴ we explain precisely what information CARF requires to be reported. Buckle up! Like many a relationship, it’s complicated. In fact, it is far more complicated than CRS reporting.

CARF’sReporting Rules

CARF⁵ requires reporting about cryptoasset users⁶ that are either (1) “reportable users”⁷ or (2) have “controlling persons”⁸ that are “reportable persons.”⁹ These are the individuals and entities that a Reporting Cryptoassset Service Provider (RCASP) will have identified by applying the due diligence procedures described in our previous article.¹⁰

Much of the reportable information consists of mundane details about the relevant individual or entity, like name, address, jurisdiction of residence, tax identification number,¹¹ and, for individuals, birthplace and date.¹² Also, for controlling persons, the RCASP must report the role that makes the person a controlling person of the entity.¹³

Naturally, the RCASP must also report its own name and address. An RCASP is also required to report its identifying number, if any.¹⁴

Mundane identifying details aside, CARF requires RCASPs to report considerable additional information. Further, they must break down their reporting by each different type of relevant cryptoasset¹⁵ for which they have effectuated relevant transactions¹⁶ during the calendar year or other appropriate reporting period.

Because reports must be filed for each type of cryptoasset, several different reports may have to be filed for a single reportable user. This would be the case, for example, if the reportable user acquired or disposed of several different types of cryptoassets or if it received or disposed of non-fungible variations on the same cryptoasset unless those variations had the same per-unit values.¹⁷

As one would expect, an RCASP must report the name¹⁸ and type of the relevant cryptoasset. Also, for all but one type of transaction, the RCASP must report both the aggregate number of units and the number of relevant transactions.¹⁹

However, exactly what an RCASP reports depends on whether the transaction involves:

•  the acquisition²⁰ of cryptoassets;

•  the disposal²¹ of cryptoassets;

•  a “reportable retail payment transaction”²²; or

•  subject to certain conditions, a transfer to a wallet address not covered by any of the above transactions.

The additional reporting required is as follows:

•  Acquisitions of Cryptoassets:

•  if the acquisition (that is, purchase) is in exchange for fiat currency, the aggregate gross amount paid,²³

•  if the acquisition is in exchange for other relevant cryptoassets, the aggregate fair market value of the acquisition.²⁴

•  Disposals of Cryptoassets:

•  if the disposal (that is, sale) is in exchange for fiat currency, the aggregate gross amount received,²⁵

•   if the disposal is in exchange for other relevant cryptoassets, the aggregate FMV of the disposal.²⁶

•  Reportable Retail Payment Transactions²⁷:

•   the aggregate FMV of the products purchased.²⁸

•  Transfers to wallet addresses not covered by any of above transactions:

•   the aggregate FMV of the amounts transferred.²⁹

Also, wallet transfers to and by a reportable user must be subdivided by the type of transfer if the type is known by the RCASP.³⁰

Further, as mentioned above, if a transfer is effectuated by an RCASP to a wallet address that the RCASP does not know is associated with a virtual asset service provider or financial institution,³¹ the RCASP must report the aggregate number of units transferred rather than the number of relevant transactions.³² In these circumstances, the RCASP does not disclose the wallet’s address in its CARF report, but must retain the information in case the local authorities need to follow up on that specific transfer.

Miscellaneous Reporting Rules

Naturally, values calculated in a fiat currency must identify the fiat currency used.³³

Also, despite the references to gross amount paid, gross amount received, and FMV, all amounts must be calculated net of any transaction fees.³⁴

The references to aggregate (that is, aggregate number of units, aggregate gross amount paid, aggregate gross amount received, and aggregate FMV) mean that an RCASP must add up and report together all transactions attributable to each reporting category for each type of relevant cryptoasset.³⁵ For example, if a reportable user had multiple different acquisitions of the same type of cryptoasset against fiat currency in the same reportable period, the RCASP must report the number of these transactions plus the total (that is, aggregate) number of units acquired in all of these transactions and the aggregate amount paid by the reportable user for all acquisitions. If the same reportable user also had multiple reportable retail payment transactions in the same year, the RCASP must file a separate report for each type of cryptoasset, not only of the number of reportable retail payment transactions but also of the aggregate number of cryptoasset units and aggregate FMV of those transactions.

RCASPs can rely on their cryptoasset-to-fiat currency exchange rates to determine the FMV of cryptoasset exchanges.³⁶ The CARF commentary gives the following example:

in respect of a disposal of Relevant Crypto-Asset A against Relevant Crypto-Asset B, the Reporting Crypto-Asset Service Provider may, at the time the transaction is executed: (i) perform an implicit conversion of Relevant Crypto-Asset A to Fiat Currency to determine the fair market value of the disposed Relevant Crypto-Asset A . . .; and (ii) perform an implicit conversion of the acquired Relevant Crypto-Asset B to Fiat Currency to determine the fair market value of the acquired Relevant Crypto-Asset B.³⁷

If a cryptoasset is hard to value (for example, if it is newly launched), an RCASP may assume that its value is the same as the value of the cryptoassets for which it is exchanged.³⁸

If an RCASP does not have a relevant cryptoasset-to-fiat currency exchange rate, it must use the following valuation methods in the order listed:

•  the RCASP’s internal accounting book value;

•  if a book value is not available, a value provided by third-party companies or websites that aggregate current prices of cryptoassets, but only if the valuation method used is reasonably expected to provide a reliable value;

•  if neither of the above is available, the RCASP’s most recent valuation of the cryptoasset; and

•  if a value can still not be attributed, the RCASP’s reasonable estimate of value.³⁹

Moreover, RCASPs relying on valuation methods other than the cryptoasset-to-fiat currency exchange rate must disclose which alternative method is used as part of the report.⁴⁰

Special rules control how to report transactions when loans of cryptoassets or fiat currency are secured by cryptoassets that are transferred as collateral for the loans with a loan agreement that requires the return of the collateral and the borrowed cryptoassets or fiat currency.⁴¹ These transactions must be reported as transfers and not as exchange transactions; meaning, not as acquisitions and disposals of cryptoassets.⁴² The transfers for both the borrowing and the return of borrowed cryptoassets must be reported as a “crypto loan” transfer type.⁴³ In contrast, the transfer of cryptoassets in connection with the deposit and return of the collateral must be reported as “collateral”.⁴⁴ Also, cryptoassets transferred to the lender as compensation for the loan (as the equivalent of interest) must be reported as “other.”⁴⁵

Loan transactions are distinguished from transfers of cryptoassets as compensation for fiat currency or other cryptoassets, which must be reported as exchange transactions, meaning as both acquisitions and disposals of cryptoassets.⁴⁶ If an RCASP doesn’t know the nature of a transfer of cryptoassets, it must report it as a transfer, not an exchange.⁴⁷

We expect jurisdictions will permit RCASPs to submit CARF reports in the same ways they allow financial institutions to submit CRS reports. For many jurisdictions, this includes uploading XML files or manually entering data on the local reporting portal. However, jurisdictions themselves must use the OECD’s CARF XML schema when exchanging CARF reports with each other.⁴⁸

A mathematical formula can succinctly illustrate how much more complicated CARF reporting will be than CRS reporting. The number of distinct reports that an RCASP may be required to file in any given year is:

The number of reportable users

+ the number of controlling persons that are reportable persons

x the number of reportable transactions per reportable person

x the number of different types of transaction per reportable transaction (with two reports due for certain types)

x the number of different types of cryptoassets transacted per each transaction type

+ any of the miscellaneous grounds for even more reporting.

Well, at least that’s the end of it, right?

That’s Not Even the End of It

Is that all the reporting that will be required of RCASPs? Maybe. Maybe not. It’s certainly all that’s required by CARF itself. However, jurisdictions are free to require the reporting of additional information. For example, Switzerland’s draft CARF ordinance requires what it calls relevant RCASPs that are not Swiss RCASPs to file reports that are nowhere required by CARF itself.⁴⁹

A relevant RCASP is an RCASP with a nexus to Switzerland, regardless of whether it has a nexus to any other jurisdiction.⁵⁰ A Swiss RCASP is subject to Switzerland’s full CARF due diligence and reporting requirements. Also, a relevant RCASP is redefined as a Swiss RCASP unless it is exempt from Switzerland’s CARF due diligence and reporting obligations because it fulfils them in another jurisdiction.

In other words, under the draft ordinance, an RCASP with any nexus (as defined in the ordinance) to Switzerland that is not fulfilling CARF due diligence and reporting obligations in another jurisdiction morphs into a Swiss RCASP. Meaning, the RCASP would be subject to all the Swiss CARF due diligence, reporting, and other obligations just like a regular Swiss RCASP.

What about relevant RCASPs that are fulfilling their CARF due diligence and reporting obligations in another jurisdiction and are thus not redefined as Swiss RCASPs? They must register on Switzerland’s CARF registration portal and inform the Swiss authorities annually of both the jurisdictions in which they are fulfilling their CARF due diligence and reporting obligations and the nexus the RCASPs have to those jurisdictions.⁵¹

The moral? RCASPs with any of the five nexus connections to Switzerland must either submit themselves fully to Switzerland’s or another jurisdiction’s CARF regime and, if the latter, must inform Switzerland accordingly. There’s no escaping CARF reporting if you’re an RCASP with a nexus to Switzerland regardless of whether you have a nexus to another CARF jurisdiction.

Another aspect of the Swiss implementation of the CARF regime, which featured under CRS in Switzerland and a few other jurisdictions, is a client-notification requirement. Under the proposed Swiss version, Swiss RCASPs must notify any reportable users and reportable controlling persons before reporting them for the first time. This one-time notification requirement obliges a Swiss RCASP to inform any reportable person of the relevant details underlying and includable in the pending CARF report. To give the reportable person ample time to challenge the proposed report, client notifications are due by January 30 of the calendar year in which the reportable person will be disclosed by that RCASP under CARF for the first time.

Accordingly, for many Swiss RCASPs and those RCASPs located in CARF jurisdictions with similar client notification obligations, the reportable information must be collected, processed, reviewed, and communicated externally soon after the end of the reporting period.⁵²

Conclusion

It’s no exaggeration to say that CARF’s reporting obligations, let alone its due diligence obligations, will be a bear. Especially for an industry that has little or no experience with comparable regimes. Cryptoasset service providers — heck, any individual or entity that falls within the broad definition of an RCASP — would do well to start preparing now to get their houses in order (as soon as they sort out which houses are in scope for getting in order!). January 1, 2026, is not that far away. Mercifully, neither is help: In the next and final article in this series, we will discuss the best practices and tools available for demonstrating an effective CARF compliance program. Not to spook you, but we will also introduce CARF’s enforcement mechanisms.

¹ OECD, “Crypto-Asset Reporting Framework and Amendments to the Common Reporting Standard” (Oct. 10, 2022).

² See Paul Foster Millen and Peter A. Cotorceanu, “Old Tricks for New Dogs, Part III: Identifying Crypto Beneficial Owners,” Tax Notes Int’l, Sept. 30, 2024, p. 2153.

³ OECD, “Standard for Automatic Exchange of Financial Account Information in Tax Matters” (July 21, 2014; 2d ed. Mar. 27, 2017).

⁴ See Millen and Cotorceanu, “Old Tricks for New Dogs: The OECD’s Cryptoasset Reporting Framework,” Tax Notes Int’l, Oct. 16, 2023, p. 345; Cotorceanu and Millen, “Old Tricks for New Dogs, Part II: The OECD’s Cryptoasset Reporting Framework,” Tax Notes Int’l, Apr. 8, 2024, p. 203; and Millen and Cotorceanu, supra note 2.

⁵ See generally OECD CARF Standard, Section II and related Commentary.

⁶ A cryptoasset user is any “individual or Entity that is a customer of a Reporting Crypto-Asset Service Provider for purposes of carrying out Relevant Transactions.” OECD CARF Standard, Section IV.D.2.

⁷ A reportable user is a cryptoasset user that is a reportable person. OECD CARF Standard, Section IV.D.1.A. A reportable person is a “reportable jurisdiction person other than an excluded person.” Id., Section IV.D.7. Subject to limited exceptions, a reportable jurisdiction person is an entity or individual that is tax resident in a reportable jurisdiction. Id., Section IV.D.8. Finally, a reportable jurisdiction is a jurisdiction that has entered into a CARF automatic exchange of information agreement with the country in question. Id., Section IV.D.9. Each CARF country must publish a list of its reportable jurisdictions. Id.

⁸ Controlling persons are defined in OECD CARF Standard, Section IV.D.10. The definition, which is identical in all material respects with the definition of the same term in CRS, draws heavily on the definition of the analogous term (beneficial owners) under anti-money laundering and know your customer rules. Indeed, CARF requires that controlling persons be interpreted consistently with the 2012 Financial Action Task Force Recommendations on International Standards on Combating Money Laundering and the Financing of Terrorism & Proliferation (as updated in June 2019 pertaining to virtual asset service providers). Id.

⁹ See OECD CARF Standard, supra note 7 for the definition of a reportable person.

¹⁰ See Millen and Cotorceanu, supra note 2.

¹¹ Without an actual TIN, the report must include a functional equivalent. OECD CARF Standard, para. 3 of commentary on Section II.

¹² The required information is subject to limited exceptions. For example, a TIN is not required if the reportable jurisdiction doesn’t issue TINs or doesn’t require the collection of TINs. OECD CARF Standard, Section II.B. Also, an individual’s birthplace is not required unless the RCASP is otherwise required to obtain and report it under domestic law. Id., Section II.C. Interestingly, para. 32 of the CARF commentary on Section II.C states that a birthplace is not required unless both the RCASP is otherwise required to obtain and report it under domestic law and it is available in the RCASP’s electronically searchable data. However, Section II.C. of CARF, which this section of the commentary supposedly is explicating, does not mention a birthplace being available in the RCASP’s electronically searchable data. This disconnect is presumably because the draftsperson copied and pasted into the CARF commentary language from the analogous sections of the CRS and the CRS commentary. Under Section I.E. of CRS, a birthplace is not required unless the reporting financial institution (RFI) (CRS’s analogy to an RCASP) “is otherwise required to obtain and report it under domestic law and it is available in the electronically searchable data maintained by the Reporting Financial Institution.” The OECD needs to clarify the disconnect between CARF Section II.C and para. 32 of the commentary on that section. More specifically, the OECD needs to clarify whether the reference to a birthplace being available in RCASP’s electronically searchable data was inadvertently omitted from CARF Section II.C. or inadvertently included in para. 32 of the commentary. Until then, RCASPs and their advisers will be left scratching their heads.

¹³ For example, the role of a controlling person of a trust could be any of the following: settlor, trustee, protector, beneficiary, or “any other natural person(s) exercising ultimate effective control over the trust.” OECD CARF Standard, Section IV.D.10. Although CRS does not require controlling persons’ roles to be reported, the OECD’s proposed amendments to CRS would add that requirement. OECD, “Crypto-Asset Reporting Framework,” supra note 1, Part II, Amendments to the Common Reporting Standard, B. Amendments to the Rules, Section I.A.1.b).

¹⁴ An RCASP’s identifying number is its TIN, if any; otherwise, its business/company registration code/number, or a Global Legal Entity Identifier. OECD CARF Standard, para. 4 of commentary on Section II. Without this, an RCASP is required to report only its name and address. Id.

¹⁵ A relevant cryptoasset is “any Crypto-Asset that is not a Central Bank Digital Currency, a Specified Electronic Money Product or any Crypto-Asset for which the Reporting Crypto-Asset Service Provider has adequately determined that it cannot be used for payment or investment purposes.” OECD CARF Standard, Section IV.A.

¹⁶ A relevant transaction is any “exchange transaction” or “transfer of relevant crypto-assets.” OECD CARF Standard, Section IV.C.1. An exchange transaction is an “a) exchange between relevant crypto-assets and fiat currencies; and b) exchange between one or more forms of relevant crypto-assets.” However, as mentioned later, other transactions, such as retail transactions paid for in crypto valued over $50,000 and transfers between wallets, may also be reportable transactions. Id., Section IV.C.2 and 3. A transfer is a transaction that moves a relevant cryptoasset from or to the cryptoasset address or account of one cryptoasset user. Section IV.C.4. There is an exception, however, for transfers between accounts maintained by an RCASP on behalf of the same cryptoasset user if, based on knowledge available to the RCASP at the time of transaction, the RCASP can’t determine that the transaction is an exchange transaction. Id.

¹⁷ OECD CARF Standard, para. 10 of commentary on Section II.

¹⁸ The full name of the cryptoasset — not simply its ticker or abbreviated symbol — must be reported. OECD CARF Standard, para. 11 of commentary on Section II.

¹⁹As noted later, the exception is a transfer effectuated by an RCASP to a wallet address that the RCASP does not know is associated with a virtual asset service provider or financial institution. In these cases, the RCASP must report the aggregate number of units transferred rather than the number of relevant transactions. OECD CARF Standard, Section II.A.3.i.

²⁰ Acquisitions may be from third-party sellers or from the RCASP itself. OECD CARF Standard, para. 13 of commentary on Section II.

²¹ Disposals may be to third-party purchasers or to the RCASP itself. OECD CARF Standard, para. 15 of commentary on Section II.

²² A reportable retail payment transaction is a transfer of relevant cryptoassets for goods or services valued at more than $50,000.

²³ The amount must be reported in the fiat currency in which it was paid. OECD CARF Standard, Section II.D. If amounts were paid in multiple fiat currencies, the amounts must be reported in a single fiat currency, converted at the time of each transaction in a manner applied consistently by the RCASP. Id. If the RCASP does not know the consideration paid (e.g., when the RCASP transfers the cryptoassets, but is not otherwise involved in the purchase), the RCASP must treat the transaction not as an acquisition but as a transfer to a wallet, which requires the FMV of the transaction, not the consideration paid, to be reported (see the discussion infra under “Transfers to wallet addresses not covered by any of above transactions”). OECD CARF Standard, para. 16 of commentary on Section II.

²⁴The FMV must be determined and reported in a single fiat currency, valued at the time of each transaction in a manner applied consistently by the RCASP. OECD CARF Standard, Section II.E. A transaction in which cryptoassets are exchanged for other cryptoassets must be reported separately as both an acquisition and a disposal of cryptoassets. OECD CARF Standard, para. 18 of commentary on Section

II. For the acquisition, the RCASP must report the FMV of the assets received from the other party, and for the disposal, the RCASP must report the FMV of the assets transferred to the other party. Id. These amounts may or may not match. If the RCASP does not know both the cryptoassets disposed of and the cryptoassets acquired (e.g., because the RCASP is involved in only one side of the exchange), the RCASP must treat the transaction as neither an acquisition nor a disposal but as a transfer to a wallet, which requires the FMV of the transaction, not the consideration received, to be reported (see the discussion infra under “Transfers to wallet addresses not covered by any of above transactions”). OECD CARF Standard, paras. 19 and 20 of Commentary on Section II.

²⁵ The amount must be reported in the fiat currency in which it was received. OECD CARF Standard, Section II.D. If amounts were received in multiple fiat currencies, the amounts must be reported in a single fiat currency, converted at the time of each transaction in a manner applied consistently by the RCASP. Id. If the RCASP does not know the consideration received (e.g., where the RCASP makes the transfer but is not otherwise involved in the sale), the RCASP must treat the transaction not as a disposal but as a transfer to a wallet, which requires the FMV of the transaction, not the consideration received, to be reported (see the discussion infra under “Transfers to wallet addresses not covered by any of above transactions”). OECD CARF Standard, Commentary on Section II, para. 16.

²⁶ Id.

²⁷ Reportable retail payment transactions are only ever reported as such for the purchaser in the transaction, not the merchant. For the merchant, these transactions are reported as transfers to the merchant’s wallet address (see infra under “Transfers to wallet addresses not covered by any of above transactions”). The only retail payment transactions that are reportable are those that exceed $50,000 and even then, only if the RCASP either is acting as agent for the merchant’s customer or is required to verify the identity of the customer under domestic anti-money laundering rules. OECD CARF Standard, Section IV.C.3. OECD CARF FAQ, Section IV: Defined Terms, subsection 3, “collateralised loans” (last accessed Oct. 21, 2024). However, retail payments of $50,000 or less may be reportable as other types of transactions. For example, if an RCASP has an agreement to process payments to a merchant made in cryptoassets by the merchant’s customers but the RCASP has no relationship with the merchant’s customers, payments of $50,000 or less are treated as transfers to the merchant’s wallet (see infra under “Transfers to wallet addresses not covered by any of above transactions”). OECD CARF Standard, para. 23 of commentary on Section II. On the other hand, if the RCASP does have a relationship with a merchant’s customer, such transfers presumably should be treated as both a transfer to the merchant’s wallet and a transfer from the purchaser’s wallet.

²⁸ The FMV must be determined and reported in a single fiat currency, valued at the time of each transaction in a manner applied consistently by the RCASP. OECD CARF Standard, Section II.E.

²⁹ The FMV must be determined and reported in a single fiat currency, valued at the time of each transaction in a manner applied consistently by the RCASP. Id. Unlike the acquisitions and disposals of cryptoassets, whether against fiat currencies or other cryptoassets, transfers to wallet addresses may or may not be for consideration. Even when transfers to wallet addresses are for consideration, an RCASP may not know how much was paid. An RCASP is expected to know the FMV of the cryptoassets transferred and must include that amount in its report.

³⁰ OECD CARF Standard, Section II.A.3.g and h. The CARF commentary provides the following examples of types of transfers for this purpose, each of which would have to be categorized separately by an RCASP: transfers effectuated on behalf of a reportable user because of an airdrop (resulting from a hard fork); an airdrop (for reasons other than a hard fork); income derived from staking; the disbursement, reimbursement, or associated return on a loan; or an exchange for goods or services. OECD CARF Standard, para. 24 of commentary on Section II

³¹ Don’t be deceived by the similarities between these two terms (virtual asset service provider and financial institution) to the similar ones from CARF and CRS that we have used throughout this series of articles (reporting cryptoasset service provider and financial institution). As used here, virtual asset service provider and financial institution are as defined in the Financial Action Task Force’s anti-money-laundering recommendations. OECD CARF Standard, para. 25 of commentary on Section II. Though the corresponding CRS and CARF definitions are similar, they are far from identical. Once again, the OECD presupposes a fluency in anti-money laundering and know your customer rules on-boarding protocols that may not exist.

³² OECD CARF Standard, Section II.A.3.i).

³³ OECD CARF Standard, Section II.F. Jurisdictions may require reporting in a particular fiat currency, for example its local currency. OECD CARF Standard, para. 9 of commentary on Section II.

³⁴ OECD CARF Standard, paras. 8 and 9 of commentary on Section II.

³⁵ OECD CARF Standard, para. 10 of commentary on Section II.

³⁶ OECD CARF Standard, para. 35 of commentary on Section II.

³⁷ Id.

³⁸ OECD CARF Standard, para. 36 of commentary on Section II.

³⁹ OECD CARF Standard, para. 39 of commentary on Section II.

⁴⁰ OECD CARF Standard, para. 40 of commentary on Section II.

⁴¹ OECD CARF FAQ, supra note 27.

⁴² Id.

⁴³ Id.

⁴⁴ Id.

⁴⁵ Id.

⁴⁶ Id.

⁴⁷ Id.

⁴⁸ See Crypto Asset Reporting Framework XML Schema User Guide for Tax Administrations (October 2024 version) (last accessed Oct. 21, 2024).

⁴⁹ Draft Swiss CARF law, art. 13a.

⁵⁰ Draft Swiss CARF law, art. 2.1. The Swiss ordinance defines nexus as (1) tax residence in a jurisdiction; (2) incorporation or organization under the laws of a jurisdiction and either (i) legal personality in the jurisdiction or (ii) tax filing obligations in the jurisdiction; (3) management from a jurisdiction; (4) regular place of business in a jurisdiction; and (5) effectuating crypto transactions through a branch in a jurisdiction.

⁵¹ Although crypto exchanges and most parties caught under the narrow definition of an RCASP will invariably conduct some reportable transaction annually, if the definition broadens to include asset managers and fiduciaries, RCASPs with no reportable persons will be commonplace. With Switzerland proposing a nil report requirement for CARF (as it and many jurisdictions require under CRS), we are curious how RCASPs with no reportable persons are to balance the registration/ nonreporting consequences of relevant/non-Swiss RCASP status. For example, what if the jurisdiction of incorporation implemented CARF without a nil report and the RCASP has no reportable persons for that year — how does it prove to Switzerland that it fulfilled its reporting duties in its home jurisdiction? Must it file a nil report on the Swiss portal to be safe?

⁵² As noted in the previous article on CARF due diligence, under CRS, a well-crafted self-certification could satisfy a financial institution’s client notification requirement as part of the account documentation.

Disclaimer: This article is intended for general informational purposes only and does not constitute legal or regulatory advice. Parties should seek qualified legal counsel regarding their specific obligations under the applicable CARF/DAC8 regulations.