AdminUI Documentation

V. 1.0

Introduction

The Admin UI is the back-office UI for CoreExchange. It allows to configure and administer a running CoreExchange system.

It is easily extensible for product customization, allowing not only to tailor the structure and looks of the UI exactly to product-specific needs but also to build multiple use-case based UIs, for example one specific UI for customer services and one for system administrators, for your CoreExchange product.

This document provides an overview over the basic customer administration features and the standard Admin UI configuration.

CoreExchange Structure / Wallet Entities

Before we dive in into the variety of features CoreExchange AdminUI provides, one needs to understand the basic logical structure behind the CoreExchange wallet system.

Subsidiary 

Represents the system´s legal entity that is the legal contract partner for every  user. It has its own (closed) set of accounting accounts, and is the basis for most configurations.

User 

Represents a customer legal entity that is the legal contract partner for a subsidiary. A user can have properties (such as name/address), may have identifiers (such as email address or telephone number used for login/identification) and authentication data (e.g. password or API credentials, and security roles). A user is the owner of a wallet. The user has a verification level corresponding to the KYC process he/she has undergone.

Wallet

Represents the link between a subsidiary and a user, and is a container for wallet accounts and payment instruments.

Wallet Account

Represents a single account in a wallet with a single currency and a defined purpose, depending on the wallet account type. Typically at least one wallet account exists in a wallet, or multiple in case the wallet should support multiple currencies. A wallet account can store emoney, and its functions depend on the accounting and transaction configuration in the system.

Wallet Account Item

Represents an activity on a wallet account, that may or may not influence the wallet account balance. The wallet account items form the account statement. Typically each transaction has one or more wallet account items. The wallet account item aggregates all accounting transfers that may be required for a transaction event.

Admin UI overview

Once you have logged in with you user account, you will be presented with the Admin UI dashboard. We will reference all dashboard elements, later in this document. The menu to the left will help you to navigate through the AdminUI.

User Administration

Whenever a new customer signs up for your service a corresponding user will be created in the CoreExchange system. Every user has a wallet linked to his account. The user accounts and wallets can be accessed through the Admin UI.

Users

To access the user accounts in your CoreExchange system, go to: Menu -> Users

 

To the right, you will see a list of all accounts registered with your CoreExchange product, starting with the most recent one. The list allows you to filter by specific criteria or search for a name, email etc.

User Account

The user account gives you an overview of the data the customer has provided so far and the wallets linked to his account. Additional information like UserID, date of registration and IP address are also stored by CoreExchange and displayed here.

By default, customers can provide up to three billing and shipping addresses. The indicators next to each field indicate whether the provided data has already been verified through the KYC process or not. 

Verification Levels

Regulatory frameworks require financial institutions to apply spending limits on unverified customers.

Spending thresholds may differ depending of the regulatory framework your business fits into. Contact your regulatory body for further guidance. By default, CoreExchange comes pre-configured with the following 3 basic verification levels to address these requirements.

EMONEY_BASIC

EMONEY_UNVERFIED

EMONEY_VERIFIED

Each level has its own predefined spending thresholds and requires different KYC levels.
For more details on how to apply thresholds to verification levels, see: Limits

User Wallet

For each wallet, several statuses are applicable. Upon creation a wallet is immediately set 'active', so it can receive and initiate transfers within CoreExchange.

The same wallet can also be 'locked' through the AdminUI and is no longer allowed to be involved in any kind of financial transfers. The funds are effectively frozen within the locked customer wallet until unlocked by a service agent (e.g. set back to 'active').

 

In order to delete a wallet, the service agent needs to set its status to 'terminated', though only wallets with zero balance can be deleted. Once deleted, these will still be visible but can no longer be reactivated.

User Wallet Account

A wallet account is the actual balance holder and part of each wallet within CoreExchange. Currently, after a wallet creation, each wallet holds exactly one wallet account in the customer's home FIAT currency. It is possible to add additional wallet accounts to a wallet to support multiple FIAT currencies. Cryptocurrency and ERC token wallet accounts are created on demand. The process is triggered by the customer through the CoreExchange consumer UI. Please note that an Ethereum wallet account is required before the user can add ERC token wallet accounts.

Regulatory Compliance

If your business provides financial services to customers or businesses, it will very likely have to comply with financial regulatory and AML/CFT (Anti Money Laundering / Counter-Financing Terrorism) rules and regulations that apply in your country of residence. Contact your financial regulatory body for guidance and further information.

The CoreExchange AdminUI provides a universal interface that can handle such processes and is customizable to meet your business's needs.

KYC (Know your Customer)

If KYC rules apply to your business, you will be required to verify your customer's identity when the account has reached a certain spending threshold. The verification is usually done by matching the data on file against official documents like ID cards, passports, utility bills etc., and also by verifying the user’s data is not listed on the government's sanction lists.

Once the customer has provided the required documents these can be uploaded into the customer's account.


Admin UI distinguishes between “ID documents” and “internal documents” with the latter used for internal purposes only. Once the documents have been uploaded they will show up in the ID documents box. Select one of them and you will be presented with the following view:

In the top left corner, you will see a low-res preview of the document (click to see in full resolution) and to the right you see all details provided by the customer upon signup.

These can now be matched against the provided document simply by ticking the corresponding boxes. If the document matches the provided data, the Document can be “accepted”. If not, you can also reject it and request another document from the customer. Repeat this procedure for all documents the customer has provided in order to match all required data.

Submitting the document will change its status from “created” to “accepted”

Rejecting a document will change its status from “created” to “rejected” 

Once you verified all customer data, the status in the corresponding fields will also

change from “unverified” to “verified”

Finally, once all user data has been verified, you can increase the verification level of the customer's account and therewith also the spending threshold:

For each verification level, the AdminUI allows you to adjust the spending limits to comply with regulatory requirements. See Limits

AML (Anti Money Laundering)

If an account has been involved in fraudulent activities or has become associated with a ‘ring’ of suspicious accounts, it may be blocked for security reasons. CoreExchange provides a  watch list to keep track of suspicious accounts, see Watch List.

CoreExchange also allows to block a user at wallet level, see Wallet

Watch List

Suspicious accounts can be set on a “watch list” and will immediately appear on the dashboard for easy access. Agents can monitor these accounts for suspicious activity and ultimately block the account for security reasons or take it off the list.

Limits

Limits are by default calculated in the lead currency and cover the threshold of both, fundings and withdrawals per user account. Limits increase with the verification level (KYC). The limit configuration in the AdminUI is very dynamic and allows you to set limits based on various parameters or a combination of the same. Multiple limits can be set.

To configure a specific limit for your CoreExchange product, go to:

Dashboard -> System -> Limit Definitions

Limit parameters

Below you will find a description for each parameter in the limit configuration:

Subsidiary

Defines the subsidiary the limit should apply to (Usually 1).

Limit Group ID

The ID of the aggregated limit group.

(limits can be aggregated to groups so they can be easily applied to specific wallets and overwrite the subsidiary limit default).

Limit Context

Defines the scenario that triggers the limit.

(All events in one of the defined scenarios are affected by the limit)

Wallet Type

Defines what wallet type the limit applies to.

(optional, applies to all wallet types if not set) 

User Verification Level

Defines what verification level the limit applies to. (optional, applies to all user verification levels if not set)

Valid from - to

Defines the time frame during which the limit will apply. (“valid from” parameter must be set, “valid to” is optional.)

Limit Type

What is limited?

Amount: The total amount of a transaction

Balance: The total balance held by a wallet

Count:    The total number of transactions

TurnOver: Total turnover (all transactions) in the specified timeframe.

Limit Sub Type

Depends on the Limit type and restricts it further to a specific type of data set. See the mapping table below for more details on what subtype is available for each limit type.

Limit Currency Type

Context or lead currency

Limit Scope

Defines whether the limit applies to the entire wallet or a wallet account only. (i.e. number of trades can be limited per currency, or across all currencies the customer holds)

Limit Payment Method         

Defines what payment method the limit will apply to. (i.e minimum funding amount is 5€, but for a PayPal it can be set to 10€ by applying a payment method limit)

Limit Period

Defines a period of time where a specific limit type may apply. (i.e 10 trades/minute, 100/hour, 1000/day). Time frame calculation:


Last year: n calendar years

Running year: today - n years

For “last” parameters, time zone=UTC

Limit Period Amount

Value for Limit Period

Limit Operation

Min or Max value for the limit

Limit Value

Value for the “Count” type limit

Limit Value Amount Currency

Currency of the “Amount”, “Balance” and “Turnover” limit type.

Limit Value Amount Amount

Value for the limit

Custom Type

Currently not in use (extension point)

Possible use case:

Trades can be categorised by specific criteria. This field could allow you to set specific limits for specific trade categories. (needs development)

Description

Give your limit a name or description

Limit Mapping Table

The Limit Subtype determines which entities are considered when calculating the actual value for a particular limit (e.g. the number or amount of fundings).

The following table shows which Limit Subtypes apply for which Limit Context:

Limit Context

Limit Subtype

Description

Invoice Create

Invoice Confirm

(Amount/Count)

All / None

Invoices in all states are considered

Completed

Only Completed invoices are considered

Failed

Only Cancelled invoices are considered

Pending

Only Created invoices are considered

Login Attempt

(N/A)

P2P Send

P2P Receive

(Amount/Count)

All / None

P2P-transactions in all states are considered

Completed

Only Confirmed/Completed P2P-transactions are considered

Failed

Only Declined P2P-transactions are considered

Pending

Only Created/Confirmed P2P-transactions are considered

Payment Instrument Create

(Count)

All / None

All Payment Instruments are considered

Completed

Only Active Payment Instruments are considered

Failed

Only Locked Payment Instruments are considered

Pending

Only Created/Active Payment Instruments are considered

Payment Fund

Payment Withdraw

(Amount/Count)

All / None

All Payments are considered

Completed

Only ConfirmInProgress / Confirmed / Approved / Completed Payments are considered

Failed

Only Failed Payments are considered

Pending

Only ConfirmInProgress / Confirmed / Approved Payment are considered

Purchase Create

Purchase Confirm

(Amount/Count)

All / None

All Purchases are considered

Completed

Only Confirmed / Committed / Completed Purchases are considered

Failed

Only Failed Purchases are considered

Pending

Only Confirmed / Committed Purchases are considered

Refund Create

(Amount/Count)

All / None

All Refunds are considered

Completed

Only Completed Refunds are considered

Failed

Only Failed Refunds are considered

Pending

Only Created Refunds are considered

Shop Configuration Create

(Count)

(N/A)

Voucher P2P Create

Voucher P2P Redeem

Voucher Invoice Create

Voucher Invoice Redeem

(Amount/Count)

All / None

All Vouchers are considered

Completed

Only Activated/Redeemed Vouchers are considered

Failed

Only Cancelled Vouchers are considered

Pending

Only Created/Activated Vouchers are considered

Wallet Account Create

Wallet Account Create Per Currency

(Count)

All / None

All Wallet Accounts are considered

Main

Only Main Wallet Accounts are considered

Shop

Only Shop Wallet Accounts are considered

*

(Amount)

Amount Granularity

The amount-granularity is checked based on the Limit Amount / Currency

*

(Balance)

Available Balance

Current available account balance is considered (without reserved balance, without potential transaction)

Reserved Balance

Current reserved account balance is considered (without available balance, without potential transaction)

Total Balance

Current total account balance is considered (both available and reserved balance, without potential transaction)

Expected Available Balance

Expected future available balance is considered (without reserved balance, but including potential transaction effect)

Expected Reserved Balance

Expected future reserved balance is considered (without available balance, but including potential transaction effect)

Expected Total Balance

Expected future total balance is considered (both available and reserved balance, and including potential transaction effect)

Fees

Similar to Limits, CoreExchange also allows a highly customizable configuration of fees.

Fees are by default calculated in lead currency and can be applied on various processes in CoreExchange. Here's a breakdown of the fee parameters that can be set via CoreExchange AdminUI.

Fee parameters:

Subsidiary

Defines the subsidiary the fee should apply to (Usually 1).

Fee group ID

The ID of the aggregated fee group.

(fees can be aggregated to groups so they can be easily applied to specific wallets and overwrite the subsidiary fee default).

Fee type

Event based (see fee context)

VAT type

Depends on the customer´s country of origin VAT laws and corresponding VAT definitions in CoreExchange.

Custom type

Currently not in use (extension point)

Possible use case:

Trades could be categorised by type. This field could allow you to set specific fees for different types of trades. (needs development)

Description

Give your fee a name or description.

Fee context

Defines the scenario that triggers the fee.

Fee currency

Defines the currency of the transaction the fee will apply for.

Wallet type

Defines what wallet type the limit applies to. (optional, applies to all wallet types if not set)

User verification level

Defines what verification level the limit applies to. (optional, applies to all user verification levels if not set)

Valid from amount currency

Fee can be limited to a specific transaction amount range

Valid from amount amount

Fee can be limited to a specific transaction amount range

Valid until amount currency

Fee can be limited to a specific transaction amount range

Valid until amount amount

Fee can be limited to a specific transaction amount range

Valid from

Defines the time frame during which the limit will apply. (“valid from” parameter must be set for the fee to apply)

Valid to

Defines the time frame during which the limit will apply. (“valid to” parameter is optional.)

Base amount currency

Defines the currency the fee will be applied in. 

Base amount amount

Defines the fix fee value

Min amount currency

Minimum fee currency

Min amount amount

Minimum fee amount

(limits base amount + transaction amount multiplied by rate)

Max amount currency

Maximum fee currency

Max amount amount

Maximum fee

(limits base amount + transaction amount multiplied by rate)

Rate

fee rate (i.e 0.1 value = 10%)

Amount Granularity

Truncates the resulting fee amount to a multiple of this value. 

Payment method

Defines what payment method the fee will apply to. (i.e funding fee for SEPA can be set to 2€, but for PayPal it could be 10€ by applying a dedicated payment method fee)

CoreExchange distinguishes between a market maker and market taker. For each a dedicated fee can be set.

Transactions

The “Transactions” section of the AdminUI gives you an overview of all business transactions that have been initiated with your CoreExchange product.

The displayed business transactions depend on your concrete business case and CoreExchange setup.

In a classical cryptocurrency exchange setup, the section splits up into the following three sections:

Payments

The Payments section shows all incoming our outgoing payments initiated through a payment method that is integrated with your CoreExchange product (e.g. credit card, bank transfer, PayPal, etc.).

A payment, once initiated is set into status Created, when confirmed by the payment gateway, the status changes to Approved. And finally once the funds have been booked accordingly, the payment gets its final status: Completed 

Invoices

Invoices are manual bookings to correct a wallet´s balance if needed. This should be handled with care and only by senior management or finance staff.

Payment Administration

The “Payment Administration” section of the AdminUI allows you to interact with the system for manual corrections, matching of unmatched payments and defining how payments are routed. It breaks down into the following sections:

Payment Transactions

For CoreExchange, payment transactions may, depending on the payment service provider, break down into multiple transactions. A standard credit card payment for instance can be a two-step process, where a pre-authorization (“reservation”) is made to ensure the funds are available in the first place, until finally authorized by a second, so-called “capture” call.

The Payment Transactions list provides a detailed overview of the payment transactions including all steps involved. Additional information like payment gateway, used business contract, payment gateway request / response, etc., is also provided in this view.

 

For manual corrections of a transaction, select the concerned transaction. This will get you to the following, more detailed view:

The “update” function in this view gives you the following options to change the status of a payment transaction:

Payment Failures

When a payment failure occurs, the corresponding payment transaction is sent into the pool of payment failures for manual processing.

Unmatched Payments

In the event the system could not match an incoming payment to a corresponding  wallet, the transaction remains in the pool of “unmatched payments”. AdminUI allows you to manually match those payments accordingly with the following options:

Payment Approvals

CoreExchange allows for outgoing FIAT withdrawals to be approved manually before they are processed by the system. This is an optional step to allow a four-eye-principle process before funds leave the system.

Pending approvals can be found in the Payment Administration -> Payment Approvals

Section of AdminUI.

Select a payment you want to approve,decline or expire by clicking the transaction ID

 

SEPA Credit File Processing

For all EUR withdrawals, CoreExchange comes with a built in SEPA file generation service. The generated SEPA files are supported by all european Banks and can usually be uploaded through the bank´s online interface to process the payments.

Once generated, the file will appear in the AdminUI interface where it can be either accepted or rejected.

If you approve the file, it transitions into “approved” status and you can download it for further processing by the bank. Once you have done that, please mark the file as “sent to bank”. When the file gets processed by your bank, mark the file as “accepted by bank” accordingly.

When you reject the file, AdminUI will ask you to mark the failed items within the file. Those are then set to status “failed” and the corresponding customer(s) get notified. The remaining transactions are moved back into the pool of unprocessed transactions waiting to be considered in the next file CoreExchange generates.

Should the bank, for any reason reject the file however, you can mark the file as “rejected by bank” which also results in changing the status of the transactions it contained to “failed”. The funds are credited back to the corresponding wallet account(s) and the customer(s) get notified about the failed withdrawal.

Remittance Credit File Processing

For all other FIAT withdrawals, CoreExchange also supports SWIFT file generation. The generated SWIFT files are supported by all banks and can usually be uploaded through the bank´s online interface to processing the payments.

The AdminUI process for SWIFT files is the exact same as for SEPA files, which is described above.

Business Contracts

Each payment method you integrate with CoreExchange, must have at least one business contract in order to route transactions. A business contract defines what type of transactions are supported by the provider of choice, and in what currency.

BIN Groups

For credit card business contracts, AdminUI allows to narrow down a contract to a specific BIN range. This can be done by creating a BIN range group and assign it to a business contract in the “business contract route list”

 

Trading

The Trading section of AdminUI allows you to configure existing and setup new trading pairs (Markets). It also provides back office tools to keep track of trades and deals on the CoreExchange platform.

Markets

When you first set up CoreExchange, the markets section will be empty and have to create the markets you wish to offer your customers. For this, go to:

Trading -> Markets

And hit the “create market” button in the upper right corner.

Subsidiary ID:                Usually: 1 (CoreExchange runs with no subsidiaries by default)

Currency 1:                 Enter the abbreviation of the first currency here (i.e. XBT)

Currency 2:                 Enter the abbreviation of the first currency here (i.e. ETH)

Qualifier:                 Public (made available to all customers)

Description:                  Custom name/description for the market

Before a new market goes live CoreExchange allows you to adjust the  market´s parameters accordingly. For this select the newly created market and you will be presented with the following screen.

The section up top lists all the details you just provided during market setup process. In addition you can pause, lock or delete the corresponding market here.

The lower section allows for more detailed adjustments to the market. The individual parameters are explained in the trading engine documentation which can be provided upon request.

Before a market can finally go live you have to set the market´s affinity first. This can be done in the lower section and requires the parameter:

Instance Affinity:                market.instance.default

The market is now ready to be set active and made available to all customers. Click “Activate” to activate the market.

Orders

The orders screen provides an overview of all trade orders that have been created in chronological order. The action button to the right helps you to jump right to a specific order, wallet, user account etc. to see more details.

Deals

The deals section provides an overview of all closed deals (executed trade orders). These can be filtered by: market, wallet account, trade deal status, date etc.

Each listed deal is linked to the corresponding buyer and seller wallet and wallet account for easy access.

ERC20 Tokens

CoreExchange supports all ERC20 Tokens. The configuration of a new token is described below.

Important notes

  • Order of the steps is important here if you want to avoid errors and annoyances for your users!
  • After the token is activated/enabled below, the token will be immediately visible to consumers logged in to their accounts, and users will be able to create their corresponding wallet accounts.
  • The initial limit definitions will be similar to the ones that are defined for Ethereum at the time the token is being activated/enabled, but they will all be set to disabled. You absolutely should review and adjust the individual limit definitions for the token

Configuration Procedure

  • Identify the token you want to configure, particularly its token contract address and the number of decimals it defines.
  • Define a token currency code (unique!), name, and a description that you want to use in CoreExchange for the token. The currency code may be the same as the ‘‘symbol’ the token itself defines as long as that code is not yet used in CoreExchange.
  • Define the Consumer UI translations for the token currency code.
  • Update the Consumer UI deployment to be prepared for the upcoming support for the token.
  • Define a unique currency number to use for the token in CoreExchange.
  • Create the token configuration using the CoreExchange Admin UI
            System → ERC20 Tokens → Create ERC20 token configuration



by using:

 

  1. The token contract address
  2. The currency code
  3. The currency number
  4. The decimal digits the token uses
  5. A defaultFormatString suitable for the number of decimal digits, for example
    “%s %0.018f” (without the quotes) if you want the default format to be the currency code followed by the amount as a floating point number with 18 fractional digits
  6. Any name you want to use for the token
  7. Any description you want to add
  8. Investigate and define the initial exchange rate for the token currency from/to the lead currency
  • Activate the token using the CoreExchange Admin UI
            System → ERC20 Tokens → use the button ‘Enable/Activate’ 



  • Review & update the limit definitions created for the token, and enable those you want to be enabled (all limit definitions are initially set to ‘disabled’)
  • Define and configure any fee definitions you want to be applicable for the token in CoreExchange Admin UI or using the API.
  • Create and configure any markets for the token you want to support (usually tokens are traded against Ethereum, but you may also want to support trading them for the lead currency), including the trading maker fees and trading taker fees.