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 the product.
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 that 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”