User Guide

Dashboard

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 CoreWallet system. Every user has a wallet linked to his account. The user accounts and wallets can accessed through the Admin UI.

Users

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

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

User Details

The user details give you an overview of the data the customer has provided so far and the wallets linked to his account. Additional information like date of registration and IP address are also stored by CoreWallet 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, CoreWallet 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 to 'active', so it can receive and initiate transfers within CoreWallet.

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 CoreWallet. 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.

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 CoreWallet 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. CoreWallet provides a  watch list to keep track of suspicious accounts, see Watch List.

CoreWallet 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 CoreWallet 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, CoreWallet also allows a highly customizable configuration of fees.

Fees are by default calculated in lead currency and can be applied on various processes in CoreWallet. Here's a breakdown of the fee parameters that can be set via CoreWallet 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)

Transactions

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

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

In a classical emoney wallet 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 CoreWallet 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 CoreWallet, 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

CoreWallet allows for payments 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

 

Business Contracts

Each payment method you integrate with CoreWallet 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”