Best Practices for Enterprise Crypto Account Management — Part II

7 min readDec 13, 2022

Kai Schmitz-Hofbauer and Andreas Vogel

This is Part II of a three-part article series. Part I, Part III

Introduction

While the core features of consumer and enterprise software solutions are often similar, enterprises typically have a number of additional requirements. This also applies to the case of crypto wallets. After we have taken a closer look at different types of wallets in part one, we will describe typical enterprise requirements for crypto account management in more detail in this article.

With regard to these requirements, a distinction must be made between:

requirements for the wallet or the wallet provider and
requirements for enterprise-appropriate usage of a wallet. Enterprise requirements in this environment arise in particular from embedding the wallet in security, compliance, finance and service processes as well as requirements for integration in the existing IT landscape.

Requirements for wallets can also be divided into

functional requirements (e. g. supported tokens, access to DeFi protocols)
non-functional requirements (e. g. technical availability, service & support capabilities of the wallet provider)

Important best practices for meeting these requirements are discussed in the following sections.

Compliance with regulatory requirements

In most countries, financial transactions involving crypto currencies are regulated by supervisory laws in the same or similar way as traditional financial transactions. Although regulation is seen by some as a major bureaucratic obstacle hindering progress, cases such as the downfall of FTX and other crypto enterprises have shown how important regulated and audited crypto services are to businesses and private users.

In most countries, the regulation includes in particular crypto custody and crypto transfer — at least as long as the respective crypto assets are classified as securities. It is therefore crucial to ensure that the selected wallet/custody provider has an appropriate license from the responsible supervisory authority. This can usually be checked on the website of the respective authority. For example, in Germany the BaFin (“Bundesbehörde für Finanzaufsicht” — German Federal Financial Supervisory Authority) provides a publicly available list of licensed custodians (select crypto custodian as category and click on search).

At the same time, this means that non-licensed wallets are not eligible for regulatory-relevant use cases, including trading & payments via crypto currencies. In the European market, the MiCA (Market in Crypto Assets) regulation will provide an uniform legal framework.

In addition to the regulatory approval, the wallet or custody provider shall also have external IT security audits and certifications such as SO/IEC 27001 as well as other audits required for the target market (e. g. FIPS140–2 as US-governmental or banking standard).

Workflow and policy support

Financial transactions in the enterprise normally require the approval of more than one person (“four eye principle”). It is therefore important that the wallet to be used has appropriate workflow and policy capabilities to ensure that transactions via the wallet comply with the company’s rules and regulations. Policies can be more complex than a pure four eyes principle. For example, value thresholds, initiator or recipient of a transaction can be considered in a policy to decide whether a transaction should be blocked or executed.

Access control and security governance

Whenever crypto wallets are used in the enterprise environment, it is important to secure access to the wallets organizationally and technically. Unlike retail or private users, wallets must support complex, changing permission structures.

Therefore, user-oriented non-custodial wallets should not be used productively in the enterprise environment. In addition to the compliance requirements already described, the secure storage of private keys that are not permanently tied to employees is particularly difficult to manage internally. Even though passphrases and passwords can of course be stored securely, it is extremely difficult to change them when personnel changes.

It is therefore recommended to rely on state-of-the-art enterprise approaches. For wallets that allow user login, the company’s technical identification & authorization management system should ideally be used to manage wallet access as well (e.g. LDAP-based systems or Microsoft Active Directory). In any case, multi-factor authentication (MFA) is a best practice to secure the login process.

Automated, programmatic interaction with the wallet takes place via an API (Application Programming Interface). For authentication, an API key is usually used instead of the classic username/password pair. The API key consists of a longer character string to which authorizations are assigned at a central location.

The API key, which is required for the programmatic, automated execution of transactions, must also be secured. It is crucial that no API keys are stored directly in the program code and certainly not to post them (accidentally) in public source code repositories. It is a best practice to use special, secure services for storage for API keys. Good candidates are AWS secrets manager or Azure key vault. A best practice is also to rotate API keys periodically and to establish emergency change procedures in case an API key has been compromised.

Organizational obligations for enterprises include having a clearly defined role and authorization concept that defines which roles, which users and which systems have which access rights to the wallet. In this context, it is also necessary to clearly define how onboarding and offboarding processes work for employees and systems. This is the case, for example, when employees need new authorizations or access rights need to be reduced when they change roles or leave the company. In the latter case, it is also advisable to set up emergency offboarding processes. The roles and authorization process shall also define how access can be logged and the intervals at which process audits are to be carried out. A role and authorization concept must not only be created once, but must be continuously updated.

Integration in existing IT landscapes

To realize their full potential, wallets must be integrated with the systems that map the business processes. In regard to the financial processes, this is usually an ERP system such as SAP; for use cases involving NFTs (Non-Fungible Token), this could be a content management system or a shop system.

Of course, to enable this kind of enterprise integration, a programmatic API access to the wallet is required.

Integration of crpyto wallets in IT landscapes

For the sake of completeness, it should be mentioned that blockchain applications do not necessarily require a classic backend. With the use of smart contracts, it is also possible to execute business logic directly on the blockchain. However, as of today classic applications are more likely to be found in the enterprise environment.

Integration in business & service processes

It can be assumed that every technical component fails at some point. This also applies to wallet software. If business processes are based on the use of a wallet, it must be ensured in particular that

the wallet provider offers suitable SLAs (Service Level Agreements like availability, response times, fault resolution times and data recovery policies) for fault clearance and that
the processes are suitably integrated with own processes, so that the business impact is minimal in case of an issue.

Relevant procedures should be clearly defined and tested before going live.

Audit trails

From a company’s point of view, it is important that the wallet used is able to generate audit trails. This is an immutable list of all transactions including the approvals that led to them. On the one hand, this is important from a risk perspective to identify faulty and fraudulent transactions. On the other hand, there are use cases where an audit trail is required for compliance reasons.

Integrating with account and reporting solutions

Fungible and non-fungible assets need to be accounted for and reported.

Relevant resources can be found below:

This has also implications where and how to handle these assets in your ERP systems to enable accounting and reporting.

Staging: use of sandbox environments, test networks and CI/CD pipelines

Before anything goes live, it is crucial to ensure end-to-end operability in at least one non-production test or sandbox environment. This includes both the respective wallets and the wallet’s use of the respective blockchain’s testnets. The testnets allow functionality to be developed and quality assured without real liquidity and transaction fees. It is important that the wallet also provides integration with the testnets for mentioned purposes.

It is advisable to run test environments permanently in parallel to the productive environments. This allows errors to be reproduced and innovations to be tested — ideally as part of an automated CI/CD pipeline (Continuous Integration/Continuous Delivery).

Functional requirements to the wallet

Of course, it is crucial that the wallet offering supports the functional requirements that depend on the respective use cases.

Which functional requirements can play a role and how in total will be discussed in more detail in the third part of the series. Token coverage, access to DeFI protocols and the integration with crypto exchanges may be a few of them.

Now that we have taken a closer look at different types of wallets and typical requirements in the enterprise environment, we put both topics into the context of specific use cases and discuss how to select the right wallet.

In Part III we will draw the conclusion which wallets will be best suited for what kind of use case.

To be continued.