# Administration Source: https://docs.finhost.io/administration ## 👥 Administrators Tab **Administrators** is the place where is represented all information about each member of the Clients’ admin team. Here is possible to add a new member of the admin team as well. ### ➕ Adding a new administrator To invite a new member of the admin team please follow the next steps: 1. Press **\[+ Add Administrator]** 2. Fill in the form with appropriate data: *first and last name, email, and role* 3. Press **\[Add]** Once the user was added to the admin panel, this user has to receive an invitation letter on the provided email with the details about the **username** and **temporary password**. Using these credentials it is possible to log in to the back-office. *** ### 🧩 Roles A role refers to a predefined set of permissions and responsibilities assigned to a user or a group of users. Roles are used to define the level of access and the specific actions that users with that role can perform within the admin panel. Currently, within the system, there are **three roles available**: * **Supervisors** – see all functionality, can interact with all functions. * **Compliance** – see all functionality. * **Restricted by back-end:** * Cannot add admins with role compliance/supervisors * Cannot edit role (any role) * Cannot delete admin with any role * Cannot enable/disable admin with any role * **Admins** – don’t see the following elements: * “Requests” tab * “Configurations” tab in view Individual/Corporate * Info about AML in view transaction * “Return” button on “transaction details” page of transaction with aml failed status **Restricted by back-end:** * Create transaction (for mock provider) * Get requests * Get transactions in pending AML, failed AML, and manual review * Return the AML failed transactions * Approve/reject requests * Approve/reject manual review * Inside transaction details, get info about AML and manual review * Get account configurations on the user’s level * Add admins with role compliance/supervisor * Cannot edit role * Cannot delete admin with any role * Cannot enable/disable admin with any role *** ### 📋 Administrators Table The table on the tab **Administrators** contains the following information about each admin: * First name * Last name * Email * Role(s) * Date of the last update For each Admin, it is possible to perform the following actions: * **Enable/Disable** – once the Admin’s account is disabled then the user is not able to log in to the White Label Admin panel. After a new Admin is created – he/she is automatically enabled. * **Edit** – the following info can be edited: first name, last name, and role. * **Delete** *** ## 📑 Contracts The **contract** is a set of configurations that should be applied to the end user of the White Label Client application and determine a set of rules within the system applied to this user. At this moment, these rules relate to: * **Fees** that should be paid for some actions within the system * **Limits** of bank accounts allowed to open **Service** is any action the user might be charged for: Internal transfer, SWIFT, SEPA, SEPA Instant, UK Faster Payment, and Crypto Exchange. Each contract should have the following characteristics: * Id * User type – individual or corporate * Contract title * Creation date and time * Status: active or archived * Details Inside each contract, except for the info described above, there is also: * Short description of contract characteristics or peculiarities if applicable * Fee per each available payment method * Limits of bank account that is possible to create per one user ⚠️ From the security prospects, contract configuration currently is possible **only via AWS service**. Further such possibility might be added to the user interface of the admin panel. *** ### 📝 Configuring contracts To configure the contract the Client has to fill in the following information: 1. Contract name 2. User type (individual/corporate) 3. Account limits: maximum number of accounts possible to create in each of available currencies 4. Fees per different services To set up the fees the following information should be filled in: * **Service**: e.g. Internal transfer, SWIFT, SEPA, SEPA Instant, UK Faster Payment, Crypto Exchange * **Currency**: EUR, USD, GBP, PLN, BTC, ETH, USDT, USDC, TRX * **Amount range(s)**: maximum 3 ranges “from-to” per each service * **Fee types**: * Min between flat and percentage * Max between flat and percentage * Sum of flat and percentage * Flat * Percentage 📌 There are no limits on how many contracts the Client may configure. Each end user is eligible to select the most preferable contract at the last stage of onboarding as well as change it later. *** ## 💵 Revenue accounts All the fees that are collected from transactions in the White Label system should be transferred to a separate account – a **revenue account**. There should be separate revenue accounts for each currency and each Provider. Before end users onboarding it is required for the Client to: * Sign up for the Client part of the White Label solution * Pass KYC/KYB (if corporate) * Open a bank account in each available currency * Provide the development team with the account details Once an account is marked as **revenue**, it won’t be charged while doing any transfers. *** ## 📬 Requests (Manual mode) On this page, you will receive all requests from users that have a **Mock provider** (BaaS provider that works in manual mode). Manual mode is designed to enable launching the setup as quickly as possible, without needing to wait for API integration with the banking provider to be completed. This feature allows you to start your business without API integration, managing account issuing and transfers manually via Finhost and the banking provider back offices while integration is in progress. Once the API integration is complete, we ensure a smooth transition from manual operations to automated processes for account issuing and payment processing. Currently, we have such types of requests: * **Create user** – to create user, you need to provide the external ID * **Create bank account** – to create a bank account you need to provide: * IBAN * BIC/SWIFT * External account ID * **Create a transfer** – it could be SEPA, SEPA Instant, Internal, UK Faster payment, or Swift.\ With this request, you will see the window with details of transaction and only approve or reject the transaction. * **Create Fee transfer** – this request is created automatically after you approve the request for creation of a transfer. *** ### 🧩 1. Create Account Here you can see three schemas that illustrate the sequence of actions when **creating an account** and **processing transactions** in manual mode. Create Account Mock #### Step 1 — User Action The user clicks **“Get Bank Details”** on their account. User Get Bank Details #### Step 2 - Slack Notification Once the user initiates account creation, a **Slack notification** is automatically sent to the internal operations channel. These notifications are internal and allow the team to track newly initiated account requests in real time.\ They are not visible to end users. #### Step 3 — Provider Verification After the first account creation request, the system will prompt the creation of a **user**.\ This information must be submitted to the banking provider.\ Once the end user is **accepted** by the provider, you can proceed with user and account creation in the provider’s portal. 🧾 Creating User 1. Submit user information from Finhost to the provider’s onboarding system. 2. Wait for the provider to approve and return the **User ID**. 3. Copy the **User ID** and insert it into the Finhost Backoffice field **External User ID**. Backoffice User Create Backoffice User Create Some banking providers do not have a separate “User” entity — they only support “Accounts.”\ In such cases, simply approve the user creation step in the Finhost Backoffice. After the **User** is created on the provider’s side, the **User ID** should become available.\ Insert this ID into our field **External User ID**.\ This is essential for the upcoming transition to **API-based automation**. #### Step 4 — Admin Account Creation Once the user is created and verified on the provider’s side, the **Admin** can create an account for that user in the Finhost Backoffice. Backoffice Bank Details Create After the **Account** is created on the provider’s side, the **Account ID** should be available.\ Insert this ID into our field **External Account ID**.\ This will be critical when all accounts are migrated under **API automation**. *** ### 💸 2. Create Outgoing Transaction General Schema Manual Outgoing Transaction Schema This diagram illustrates the general process of how an outgoing transaction is created and processed in **manual mode**. *** #### Step 1 — User Initiates Payment The user initiates a payment request through their account interface. User Initiates Payment *** #### Step 2 - Slack Notification Once the user initiates outgoing payment, a **Slack notification** is automatically sent to the internal operations channel. These notifications are internal and allow the team to track newly initiated account requests in real time.\ They are not visible to end users. #### Step 3 — Admin Initiates Payment on Provider Side Once the user submits a payment request, an **Admin** must manually initiate this transaction in the **banking provider’s portal**. It’s important to wait until the payment is **approved** by the banking provider before proceeding with any actions inside Finhost Backoffice. *** #### Step 4 — Approve or Reject Transaction in Finhost Backoffice After receiving a response from the banking provider, the Admin should review the transaction in **Finhost Backoffice**. Approve Transaction in Backoffice ✅ Approving a Transaction If the payment is approved on the provider’s side: 1. Approve the transaction in Finhost Backoffice. 2. Insert the **External Transaction ID** received from the provider. Inserting the correct **External Transaction ID** is essential for maintaining synchronization between the provider’s system and Finhost Backoffice during API automation. ❌ Rejecting a Transaction If the payment is **rejected** by the provider: * Use the **Reject** button in Finhost Backoffice. * You can specify a **rejection reason**, if available from the provider.\ This reason will **not be visible to the end user**, but it will remain stored internally for your operational records. *** #### Step 5 — End User Notification and Balance Update Once the transaction is approved and the external ID is recorded: * The **end user receives an email notification** confirming the payment. * The **account balance** is automatically updated. * The transaction status changes to **Completed**. *** #### Step 6 — Fee Transaction Approval Since this is **manual mode**, once the main payment is approved, a **fee transaction** will be created automatically. Fee Transaction Approval After approving the main payment: 1. Locate the automatically generated **fee transaction** in Finhost Backoffice. 2. Review and **approve it** to finalize the payment flow. Always ensure the fee transaction is approved immediately after the main payment to maintain accounting accuracy and ensure consistent balance synchronization. *** *** ## 💰 3. Create Incoming Transaction Manual Incoming Transaction This diagram illustrates how incoming transactions (deposits) are processed in **manual mode**. *** #### Step 1 — Monitor Provider Dashboard The first task for the **Admin** is to regularly monitor the **banking provider’s admin dashboard** to identify new incoming deposits. We highly recommend enabling **email or system notifications** (if supported by the provider) to ensure that deposits are credited to end users’ accounts **as soon as possible**. *** #### Step 2 — Log the Deposit in Finhost Backoffice Once a deposit is visible in the provider’s system, it needs to be logged manually in Finhost Backoffice. Manual Incoming Transaction Manual Incoming Transaction 1. Open the **Create Transaction** page. 2. Select **Incoming Payment** as the transaction type. 3. Choose the appropriate **payment method**. 4. Search for the target account using one of the following options: * **Internal Account ID** * **Account Number** * **IBAN** If the user deposits to a **pooled account** and is identified via the **payment reference**,\ use the **Reference ID**, which corresponds to the **Internal Account ID** in our system. If the user deposits to a **dedicated banking account**, you can use the **Account Number** or **IBAN** for convenience. *** #### Step 3 — Complete Transaction Details Fill in all required fields according to the **sender’s information** provided by the banking provider.\ Ensure that the sender’s name, payment reference, and amount match the details shown in the provider’s dashboard. *** #### Step 4 — Confirm Deposit Once the transaction is created and confirmed: * The **user’s balance** will be automatically updated. * An **email notification** will be sent to the end user confirming the deposit. * The transaction status will change to **Completed** in Finhost Backoffice. *** Always verify sender details carefully before approving the transaction to avoid misallocating funds between accounts. ## 💠 Crypto Module Administration Guide ### 1. Introduction The **Crypto Module** connects fiat and crypto operations through two main providers: * **Fireblocks (FB)** — manages crypto wallets, generates deposit addresses, and processes incoming and outgoing crypto payments. * **Kraken (KR)** — handles all crypto–fiat conversions using **market orders** for real-time liquidity. Together, these systems enable your clients to exchange between fiat (e.g. EUR) and crypto (e.g. BTC) without manual intervention.\ The flow relies on **centralized liquidity** and does **not** create separate accounts for each client on the providers’ sides —\ **all client balances are handled and reflected within the Finhost Core Banking Ledger**, which tracks and synchronizes virtual balances for end-users. *** ### 2. How Money Flows Work #### 🔄 A. Fiat → Crypto Exchange and Withdrawal **Example:** Convert EUR to BTC and send out. **Steps:** 1. The user creates a **EUR account (Acc A)** with SEPA and Crypto Exchange capability (supported by the **Fiat Provider**).\ → An account is created on the Fiat Provider side. 2. The user creates a **BTC account (Acc B)** (supported by **Fireblocks** and **Kraken**).\ → No individual wallet is created on the provider’s side; Finhost uses Fireblocks and Kraken **master accounts** for all clients. 3. The user receives EUR via SEPA to **Acc A**, reaching a balance of *100 EUR*.\ Funds are settled on the Fiat Provider account. 4. When the user requests to exchange EUR → BTC: * The conversion takes place on **Kraken** via a **market order**. * **Acc B** (BTC) balance is updated to *0.0017 BTC* within the Finhost Core Banking Ledger. * ⚠️ **Important:** To perform this conversion successfully, there must be **enough liquidity on the Kraken side** in the respective fiat currency (e.g. EUR). Insufficient liquidity will cause exchange delays or failures. 5. When the user withdraws BTC:\ The transaction flow is **Kraken → Fireblocks Master → External crypto address**. Crypto Withdrawal *** #### 🔁 B. Crypto → Fiat Exchange and Withdrawal **Example:** Convert BTC to EUR and withdraw via SEPA. **Steps:** 1. The user creates a **BTC account (Acc A)** (supported by **Fireblocks** and **Kraken**).\ → A unique Fireblocks crypto address is generated for the user to receive and send crypto funds. 2. The user creates a **EUR account (Acc B)** with SEPA and Exchange capability (supported by the **Fiat Provider**).\ → An account is created on the Fiat Provider side. 3. The user deposits *0.0017 BTC* to the crypto address. * Fireblocks receives the transaction and transfers it to the **Kraken Master Account** for liquidity and trading availability. Crypto Withdrawal 4. When the user exchanges BTC → EUR: * The conversion happens on **Kraken** using a market order. * **Acc B** (EUR) balance updates to *100 EUR* within the Finhost Core Banking Ledger. 5. The user withdraws EUR: * The flow is **Kraken → Fiat Provider → External recipient (SEPA Out)**. * ⚠️ **Important:** To initiate and complete the withdrawal successfully, there must be **enough liquidity on the Fiat Provider side** in the respective currency (e.g. EUR). Otherwise, the payment initiation will fail or remain pending. *** ### 3. Reconciliation & Liquidity Management The **Admin** is responsible for maintaining sufficient liquidity on both **Fiat** and **Crypto** sides.\ These systems are **independent** — the Fiat Provider does not see Crypto Provider balances, and vice versa. #### ⚙️ Initial Setup Requirements Before enabling crypto exchange for a currency, ensure liquidity is pre-deposited on both providers’ sides. **Example:**\ If you plan to enable **EUR** for exchange: * Deposit liquidity in **EUR** on the **Fiat Provider** side. * Deposit liquidity in **EUR** on the **Kraken** side. 💡 **Recommendation:** Maintain at least **30 % of total client balances** as available liquidity on each side to ensure smooth operations and prevent conversion or withdrawal delays. #### 📊 Reconciliation Reports Use the **[Reconciliation Report](https://docs.finhost.io/reports-dashboard#4-reconciliation)** in the Backoffice to: * Compare total client balances (from the Core Banking Ledger) with available funds in Fiat and Kraken accounts. * Quickly detect shortages and top up liquidity where needed. *** ### 4. Gas Station (Crypto Network Fees) Fireblocks requires a **Gas Station wallet** to cover blockchain transaction fees (“network fees”) for outgoing crypto transfers.\ If the Gas Station runs out of funds, **crypto payments will fail** until refilled. Check fireblocks recommendations [https://support.fireblocks.io/hc/en-us/articles/9378061609884-Default-Gas-Station-values](https://support.fireblocks.io/hc/en-us/articles/9378061609884-Default-Gas-Station-values) #### 🔋 How to Manage 1. Open **Fireblocks Console → Settings → Gas Station**. 2. Review available balances for each supported network (BTC, ETH, USDT). 3. Refill balances as needed according to Fireblocks recommendations: * **BTC:** \~0.01 BTC * **ETH:** \~0.1 ETH * **USDT (ERC-20):** enough for ≈ 10 outgoing transactions 🪙 Keep the Gas Station **prepaid at all times** to ensure uninterrupted crypto operations and avoid failed withdrawals. *** ### 5. Supported currencies & network fees The following table shows the currencies and networks currently supported in the Crypto module, together with their corresponding Fireblocks asset mapping and minimum amounts for deposits and withdrawals. | Currency | Network | Type | Fireblocks mapping | Deposit minimum | Withdraw minimum | | -------- | -------- | ----- | ------------------------- | --------------- | ---------------- | | BTC | bitcoin | Coin | `BTC` | 0.0005 | 0.0002 | | ETH | ethereum | Coin | `ETH` | 0.02 | 0.005 | | ETH | arbitrum | Coin | `ETH-AETH` | 0.02 | 0.005 | | ETH | base | Coin | `BASECHAIN_ETH` | 0.02 | 0.005 | | ETH | optimism | Coin | `ETH-OPT` | 0.02 | 0.005 | | USDC | ethereum | Token | `USDC` | 20 | 20 | | USDC | arbitrum | Token | `USDC_ARB_3SBJ` | 10 | 10 | | USDC | base | Token | `USDC_BASECHAIN_ETH_5I5C` | 10 | 10 | | USDT | ethereum | Token | `USDT_ERC20` | 20 | 20 | | USDT | tron | Token | `TRX_USDT_S2UZ` | 10 | 10 | | TRX | tron | Coin | `TRX` | 40 | 30 | *** ### ✅ Summary Checklist for Administration | Task | Frequency | Responsible | | --------------------------------- | --------- | --------------- | | Review Reconciliation Report | Daily | Admin | | Check Fireblocks Gas Station | Weekly | Admin | | Review Fiat & Kraken Balances | Weekly | CFO / Admin | | Monitor Exchange Orders Execution | Daily | Support / Admin | *** # Activate the account of the customer Source: https://docs.finhost.io/api-reference/account/activate-the-account-of-the-customer patch /account Process receiving account banking details # Activate the account of the customer Source: https://docs.finhost.io/api-reference/account/activate-the-account-of-the-customer-1 patch /v1/accounts/{accountId} Process receiving account banking details # Create statements for account Source: https://docs.finhost.io/api-reference/account/create-statements-for-account post /v1/accounts/{accountId}/statements Return the list of the completed transactions for the client accounts in # Get bank details for extAccount Source: https://docs.finhost.io/api-reference/account/get-bank-details-for-extaccount-client-api get /v1/ext-accounts/{extAccountId} Return the list of the balances for the client accounts # Initiate a new account for the customer Source: https://docs.finhost.io/api-reference/account/initiate-a-new-account-for-the-customer post /v1/accounts Initiate a process of creation a new financial account for the customer # Receive all accounts for the client Source: https://docs.finhost.io/api-reference/account/receive-all-accounts-for-the-client-client-api get /account Return the list of the balances for the client accounts # Receive all accounts for the client Source: https://docs.finhost.io/api-reference/account/receive-all-accounts-for-the-client-client-api-1 get /v1/accounts Return the list of the balances for the client accounts # Receive all accounts for the client Source: https://docs.finhost.io/api-reference/account/receive-all-accounts-for-the-client-client-api-2 get /v1/accounts/{accountId} Return the list of the balances for the client accounts # Receive bank detailes for the account Source: https://docs.finhost.io/api-reference/account/receive-bank-detailes-for-the-account-client-api get /account/details/{account} Account bank detailes # Activate the account of the client Source: https://docs.finhost.io/api-reference/accounts/activate-the-account-of-the-client patch /v2/accounts/{accountId} Activate the account of the client # Initiate a new client Source: https://docs.finhost.io/api-reference/client/initiate-a-new-client-client-api post /client Initiate a client with provided answers for onboarding questionnaire # Receive information about the client Source: https://docs.finhost.io/api-reference/client/receive-information-about-the-client-client-api get /client Client info # Update client contract inDevelopnent Source: https://docs.finhost.io/api-reference/client/update-client-contract-client-api-indevelopnent patch /client/contract Set the contract in the client profile # Update client Info inDevelopnent Source: https://docs.finhost.io/api-reference/client/update-client-info-client-api-indevelopnent patch /client Confirm client profile information # Accept contract for client Source: https://docs.finhost.io/api-reference/clients/accept-contract-for-client post /v2/clients/contract-accept Accept contract for client # Get KYC access token for client Source: https://docs.finhost.io/api-reference/clients/get-kyc-access-token-for-client get /v2/clients/kyc-access-token Get KYC access token for client # Accept contract for company Source: https://docs.finhost.io/api-reference/companies/accept-contract-for-company post /v2/companies/contract-accept Accept contract for company # Get Company Source: https://docs.finhost.io/api-reference/companies/get-company get /v2/companies/{companyId} Get Company # Get KYB access token for company Source: https://docs.finhost.io/api-reference/companies/get-kyb-access-token-for-company get /v2/companies/{companyId}/kyb-access-token Get KYB access token for company # List Companies Source: https://docs.finhost.io/api-reference/companies/list-companies get /v2/companies List Companies # Accept contract Source: https://docs.finhost.io/api-reference/company/accept-contract patch /companies/contract Accept contract # Create company Source: https://docs.finhost.io/api-reference/company/create-company-client-api post /companies Company info # Receive information about the company Source: https://docs.finhost.io/api-reference/company/receive-information-about-the-company-client-api get /companies Company info # Receive information about the company inDevelopment Source: https://docs.finhost.io/api-reference/company/receive-information-about-the-company-client-api-indevelopment get /companies/{companyId} Company info # Resend verification code Source: https://docs.finhost.io/api-reference/company/resend-verification-codeclient-api post /companies/email/resend-code Resend verification code # Set company email Source: https://docs.finhost.io/api-reference/company/set-company-emailclient-api patch /companies/email Set company email # Update company Source: https://docs.finhost.io/api-reference/company/update-company-client-api patch /companies Company info # Verify company email Source: https://docs.finhost.io/api-reference/company/verify-company-emailclient-api post /companies/email/verify Verify company email # Receive information about the available contracts for the clients Source: https://docs.finhost.io/api-reference/contract/receive-information-about-the-available-contracts-for-the-clients-client-api get /contracts/clients Available contracts for the clients # Receive information about the available contracts for the companies Source: https://docs.finhost.io/api-reference/contract/receive-information-about-the-available-contracts-for-the-companies-client-api get /contracts/companies Available contracts for the companies # Get Contracts Source: https://docs.finhost.io/api-reference/contracts/get-contracts get /v2/contracts Get Contracts. If company ID is provided, then contracts for specific company will be returned, otherwise contracts for client will be returned. If client or company has no contract, then list of available contracts will be returned # Get info about crypto transfer Source: https://docs.finhost.io/api-reference/default/get-info-about-crypto-exchange get /info # Receive information about iban Source: https://docs.finhost.io/api-reference/general/receive-information-about-iban get /iban/validate/{iban} # Introduction Source: https://docs.finhost.io/api-reference/introduction How to authenticate with Cognito and call the (single) Finhost Client API across payments and crypto features. This page focuses **only** on API integration. **Client → Backend only.** These APIs are designed for **front‑end clients (web/mobile) calling your Finhost backend** using end‑user tokens from **Amazon Cognito**. They are **not** intended for backend‑to‑backend calls with client secrets. ## Overview Finhost exposes a **single** REST surface called **Client API**. It includes traditional banking features (clients, companies, accounts, transfers, transactions) **and** optional **crypto‑exchange** features. * All requests are **JSON** over HTTPS with **Bearer** auth. * Crypto endpoints are namespaced under `/crypto-exchange` within the same base URL. *** ## Environments & Base URLs > Your tenant uses customer‑scoped hostnames. * **Dev**: `https://client-api.dev.{your-domain}.io` * **Prod**: `https://client-api.{your-domain}.io` Replace `{your-domain}` with your assigned tenant domain (e.g., `acmebank`). Keep these values in env vars: ```bash theme={null} export CLIENT_API_BASE="https://client-api.dev.{your-domain}.io" # or prod ``` *** ## Authentication (Cognito) Finhost relies on **Amazon Cognito User Pools** for user authentication and token issuance. ### What you need * **User Pool ID** and **Region** * **Web App Client ID** (no client secret for public web/mobile apps) * (Optional) **Hosted UI** domain if you use Cognito’s OAuth2/PKCE login ### How it works 1. Your web/mobile app authenticates the **end user** against Cognito: * **Hosted UI + PKCE** (recommended) *or* a library like **AWS Amplify Auth**. 2. Cognito returns short‑lived **JWTs**: * **ID token** (user identity claims) * **Access token** (authorization for APIs) * **Refresh token** (to renew tokens silently) 3. Your app calls Finhost **Client API** with the **Access token** in the header: ```bash theme={null} Authorization: Bearer ``` 4. On expiry, renew tokens via the **refresh token** (Amplify or Hosted UI session) and retry. Register your front‑end origins in CORS. Avoid storing tokens in `localStorage`; prefer memory or secure, httpOnly cookies where applicable. ### Example — fetch profile (JS) ```ts theme={null} const res = await fetch(`${CLIENT_API_BASE}/client`, { headers: { Authorization: `Bearer ${accessToken}` } }); const me = await res.json(); ``` ### Example — cURL ```bash theme={null} curl --request GET \ --url "$CLIENT_API_BASE/client" \ --header "Authorization: Bearer $TOKEN" ``` *** ## Canonical integration flows ### A) Individual onboarding (KYC → account → bank details → payments) 1. **Initiate client** — `POST /client` ```bash theme={null} curl -X POST "$CLIENT_API_BASE/client" \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ -d '{ "name": "John", "surname": "Doe", "nationality": "UKR", "birthday": "2017-07-21", "phone": "+380689873682" }' ``` 2. **Accept contract (client)** — `POST /v2/clients/contract-accept` ```bash theme={null} curl -X POST "$CLIENT_API_BASE/v2/clients/contract-accept" \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ -d '{"contractId": "regularContract"}' ``` 3. **Get KYC access token** — `GET /v1/kyc/access-token` (for Sumsub Web SDK) ```bash theme={null} curl -X GET "$CLIENT_API_BASE/v1/kyc/access-token" \ -H "Authorization: Bearer $TOKEN" ``` 4. **Create account** — `POST /v1/accounts` ```bash theme={null} curl -X POST "$CLIENT_API_BASE/v1/accounts" \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ -d '{"title":"Main EUR","currency":"EUR","companyId":"","variantId":""}' ``` 5. **Fetch bank details** — `GET /v1/ext-accounts/{extAccountId}` ```bash theme={null} curl -X GET "$CLIENT_API_BASE/v1/ext-accounts/" \ -H "Authorization: Bearer $TOKEN" ``` `GET /account/details/{account}` is deprecated. Use `/v1/ext-accounts/{extAccountId}` instead. 6. **Initiate external transfer** — `POST /v2/transfer` ```bash theme={null} curl -X POST "$CLIENT_API_BASE/v2/transfer" \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ -d '{ "amount":"42", "from": {"type":"individual","accountId":""}, "payment": {"method":"sepa","recipient": {"iban":"GB33...","bicSwift":"BUKBGB22","name":"John","surname":"Doe","country":"GB"}} }' ``` 7. **List transactions (cursor)** — `GET /v1/transactions` ```bash theme={null} curl -X GET "$CLIENT_API_BASE/v1/transactions?accountId=&limit=50&sortOrder=descending&lastKey=" \ -H "Authorization: Bearer $TOKEN" ``` ### B) Company onboarding (KYB) 1. **List companies** — `GET /v2/companies` 2. **Get KYB access token** — `GET /v2/companies/{companyId}/kyb-access-token` 3. **Accept contract (company)** — `POST /v2/companies/contract-accept` *** ## Crypto features (under Client API) The crypto‑exchange feature set lives under the same base URL, namespaced at `/crypto-exchange`. * **List orders (paginated)** — `GET /crypto-exchange/orders` ```bash theme={null} curl -X GET "$CLIENT_API_BASE/crypto-exchange/orders?pageLimit=10&pageSort=desc&pageKey=" \ -H "Authorization: Bearer $TOKEN" ``` * **Get order** — `GET /crypto-exchange/orders/{orderId}` (eventual consistency) * **Create order** — `POST /crypto-exchange/orders` * **Create wallet (external account)** — `POST /crypto-exchange/wallets` * **Create payout (transaction)** — `POST /crypto-exchange/payouts` Pagination differs by area: core banking uses `limit/lastKey`; crypto uses `pageLimit/pageKey/pageSort`. *** ## Status codes & patterns * **200 OK** — successful GET/POST (lists, tokens, reads) * **201 Created** — resource/operation created (transfers, accounts, orders) * **400 / 403 / 404** — validation/auth/lookup errors * **500** — server error **Best practices** * Include `Authorization: Bearer ` on **every** request. * Set `Content-Type: application/json` for bodies. * Prefer **cursor pagination** (`lastKey` or `pageKey`) over offset. * Prefer new endpoints under `/v2` when available. * Avoid deprecated paths such as `/account/details/{account}`. *** ## Quick reference | Feature | Endpoint | | ------------------------ | ---------------------------------------------------------------- | | Get client profile | `GET $CLIENT_API_BASE/client` | | Initiate client | `POST $CLIENT_API_BASE/client` | | Accept contract (client) | `POST $CLIENT_API_BASE/v2/clients/contract-accept` | | Get KYC token | `GET $CLIENT_API_BASE/v1/kyc/access-token` | | List companies | `GET $CLIENT_API_BASE/v2/companies` | | Get KYB token | `GET $CLIENT_API_BASE/v2/companies/{companyId}/kyb-access-token` | | Create account | `POST $CLIENT_API_BASE/v1/accounts` | | Get bank details | `GET $CLIENT_API_BASE/v1/ext-accounts/{extAccountId}` | | External transfer | `POST $CLIENT_API_BASE/v2/transfer` | | Internal transfer | `POST $CLIENT_API_BASE/v2/transfer/internal` | | List transactions | `GET $CLIENT_API_BASE/v1/transactions` | | List orders | `GET $CLIENT_API_BASE/crypto-exchange/orders` | | Get order | `GET $CLIENT_API_BASE/crypto-exchange/orders/{orderId}` | *** ## Next steps * Configure Cognito (User Pool, Web Client ID, Hosted UI/PKCE) and CORS allow‑lists. * Use **Dev** for integration; switch env vars to **Prod** at go‑live. * Enable crypto features if required; endpoints will be available under `/crypto-exchange`. # Create order Source: https://docs.finhost.io/api-reference/orders/create-order post /orders Asynchronous operation. The order may not be available in the orders list immediately after the response. # Get order Source: https://docs.finhost.io/api-reference/orders/get-order get /orders/{orderId} Eventually consistent operation. May not include the recently created orders. # List orders Source: https://docs.finhost.io/api-reference/orders/list-orders get /orders Eventually consistent operation. May not include the recently created orders. # Create payout (transaction) Source: https://docs.finhost.io/api-reference/payouts/create-payout-transaction post /payouts Asynchronous operation. The transaction may not be available in the transactions list immediately after the response. # Get client recipients Source: https://docs.finhost.io/api-reference/recipient/get-client-recipients-client-api get /recipient List of the recipients for the client # Receive internal recipient account Source: https://docs.finhost.io/api-reference/recipient/receive-internal-recipient-account-client-api get /recipient/search/{currency} Receive recipient info and default account # Receive internal recipient account Source: https://docs.finhost.io/api-reference/recipient/receive-internal-recipient-account-client-api-1 get /v1/search/recipient Receive recipient info and default account # Search recipient by alias Source: https://docs.finhost.io/api-reference/recipient/receive-internal-recipient-account-client-api-2 get /v2/recipients/search/aliases/{alias} Search recipient by alias # Search recipient by alias Source: https://docs.finhost.io/api-reference/recipients/search-recipient-by-alias get /v2/recipients/search/aliases/{alias} Search recipient by alias # Receive Sumsub (our KYB provider) access token, given the company ID (use client-api domain from servers listed above) Source: https://docs.finhost.io/api-reference/sumsub/receive-sumsub-our-kyb-provider-access-token-given-the-company-id-use-client-api-domain-from-servers-listed-above get /v1/kyb/access-token/{companyId} Requests customer token to initialize Sumsub SDK # Receive Sumsub (our KYC provider) access token for individual customer (use client-api domain from servers listed above) Source: https://docs.finhost.io/api-reference/sumsub/receive-sumsub-our-kyc-provider-access-token-for-individual-customer-use-client-api-domain-from-servers-listed-above get /v1/kyc/access-token Requests customer token to initialize Sumsub SDK # Receive all account transactions Source: https://docs.finhost.io/api-reference/transactions/receive-all-account-transactions get /v1/transactions Return the list of transactions for the client account # Receive transaction by id Source: https://docs.finhost.io/api-reference/transactions/receive-transaction-by-id get /v1/transactions/{transactionId} Return transaction # Initiate External Transfer Source: https://docs.finhost.io/api-reference/transfer/initiate-external-transfer post /v2/transfer Initiate External Transfer # Initiate Internal Transfer Source: https://docs.finhost.io/api-reference/transfer/initiate-internal-transfer post /v2/transfer/internal Initiate Internal Transfer # Create wallet (external account) Source: https://docs.finhost.io/api-reference/wallets/create-wallet-external-account post /wallets Asynchronous operation. The external account may not be available in the external accounts list immediately after the response. # Bank management Source: https://docs.finhost.io/bank-management The **"Bank management"** block is related to viewing all information about users and their transactions.\ It's divided into 4 tabs: 1. **Individuals** 2. **Corporates** 3. **Transactions** 4. **Cards** *** ## 👤 Individuals An individual is a person who has created a profile in a white label application and is authorised to access and perform various banking activities through it. Each individual might be registered only by his own via white label web or mobile interface. There is no possibility of creating an individual user via the admin panel. The represented table on page "Individuals" shows the list of all individual profiles signed up in the White Label application. Each individual contains the following information: * User ID; * First and Last name; * Phone number; * Email; * Verification Status; * State; * Date of creation; * Nationality. *** #### ✅ Verification status Represents the status of individual verification via KYC procedure. Applicable values: * **Unconfirmed** – the user hasn't submitted any documents for starting KYC procedure verification; * **Pending** – user submitted documents to the KYC service but the verification is not finished; * **Resubmission Required** – user is required to resubmit any of provided documents; * **Rejected** – user's application is rejected by KYC Service permanently; * **Confirmed** – user application is approved by SumSub; *** #### 🔐 State The value represents the state of an individual in the white label system. Applicable values: * **Active** – user has access to all functionality; * **Suspended** – functionality "Send money", and "Create accounts" are not available. Admin can unsuspend the user; * **Blocked by Admin** – user is blocked permanently. The user cannot access his profile; * **Closed** – user is closed (done on his/her own). The user cannot access his profile. The profile might be closed only if all his bank account balances are zero and there are no pending transactions. *** #### 🔎 View details Per each individual, it is possible to look through the detailed information by pressing the \[View] button. Given the details are opened the information is divided into separate blocks: * General information * Accounts * Orders * Cards *** ### 1. 📑 General information General information is divided into two main sections: personal and legal info. * **Personal** displays information user entered manually while the onboarding process. * **Legal** displays information that is pulled from the KYC service. **KYC Id** serves as a link to an external service (SumSub) and enables an admin who has access to this service to look through all the documents/details the applicant submitted for verification. Except for that info, there is also info about verification status, state, contract, and if the user has corporate, you can see the information about it. There is a possibility to search specific individuals by full phone number or user Id. *** ### 2. 💳 Accounts Here is represented the info about users' bank accounts. An admin has a right just to view those details, there is no possibility to open the account, edit, or close (delete) it. The following information is displayed per each account: * Id – unique account identifier in the white label system; * Account title – the name of the account which is automatically generated, pattern: currency\_account\_order; * Currency – available currencies EUR, GBP, USD, PLN, ETH, USDT, USDC, TRX; * Available balance – the balance resulting from all transactions (including pending status). This is the balance user sees in the app and is available to use; * Reserved balance – the balance resulted from all incomplete (pending) transactions. A total sum of currency on hold for the account (outcoming from the account); * Current balance – the balance created according to transaction that are Completed. * Created at – the date when the account was initiated; * Updated at – the date when information about the account was changed last time: status, balance, created transaction, etc. Additionally, there is detailed information for each account, where might be founded the duplicated information listed above and extra info about: **Additional info:** * Internal account ID * Account number – a unique 8-digit code that identifies users' personal bank account, applicable only for UK banks; * Sort code – a 6-digit number that identifies the bank where the account is created, applicable only for UK banks; * IBAN – identifiers of users' personal bank account; * SWIFT/BIC code – identifiers of users' bank where the account is created; * Provider; * Account variant; * Deposit address, applicable only for crypto accounts; **Internal account status values:** * Initiated – account is created on the white label side, but it is not created on the Provider side and due to this does not have account details yet; * Pending – account is in the process of changing from initiated to activated; * Activated – account is created on the Provider side. The account contains account details; * Closed – account is closed on the Provider side. *** #### ✏️ Edit account details Admins can edit the bank details of fiat accounts that use a **mock provider**. Accounts with an integrated provider (e.g. OpenPayd, BCB, Fuse) cannot be edited — the Edit button will not be shown. Only accounts with **internal status** Active or Suspended **and external status** Activated can be edited. The following fields can be modified: | Field | Currencies | Required | Validation | | ------------------------------- | ------------- | ----------------------------------------- | ------------------------------------------------------------------ | | **Account number** | GBP, USD, CAD | One of IBAN or Account number is required | GBP: digits only, exactly 8. USD/CAD: digits only, 7–12 | | **Sort code** | GBP | Required if account number is present | Digits only, exactly 6 | | **IBAN** | All | One of IBAN or Account number is required | Alphanumeric, 15–34 characters | | **BIC/SWIFT** | All | Required | Alphanumeric, 8–11 characters | | **Transit number** | USD, CAD | Optional | Digits only, exactly 5 | | **Institution number** | USD, CAD | Optional | Digits only, exactly 3 | | **Routing number** | USD | Optional | Digits only, exactly 9 | | **Intermediary bank BIC/SWIFT** | All | Optional | Alphanumeric, 8–11 characters | | **Account holder name** | All | Required | Latin alphanumeric + special symbols, max 140 chars, no diacritics | **Account holder name — shared vs dedicated:** When editing the account holder name, you must choose between two options: * **For shared IBAN/Account number** — the account holder name is editable and stored separately. A **reference** is automatically added to the account (format: `InternalAccountID-TenantShortCode`). * **For dedicated IBAN/Account number** — the account holder name is automatically populated from the user's profile and cannot be changed directly. To update it, change the user's name — the account holder name updates automatically. You cannot switch from "shared" to "dedicated" if the IBAN/account number belongs to a pool account defined in the contract's shared details. An error message will be shown: *"The account holder name type cannot be changed because the IBAN/account number belongs to a pool account."* **Important notes on editing:** * Optional fields can be cleared (left empty). * **Existing transactions retain historical data** — old transactions will continue to show the bank details that were active at the time they were created. Only new transactions will use the updated details. * After any change, an **email notification** is sent to the end user to inform them about the updated account details. * All changes are saved in the account's **history** with the date of the change. *** #### 💰 Transactions Along with the account details per each account, there is a separate section representing the list of transactions related to that account. The table with transactions contains the following information: * Id – unique transaction identifier in the white label system; * Payment method – Internal transfer, Faster Payment, SEPA, SWIFT * Remitter – first, last name; * Recipient – first, last name; * Amount – transfer amount with the fee included; * Current balance; * Available balance; * State – available values: * **Pending** – transfer is initiated and is reviewing on the white label or already on the Provider side but still is not approved by the Provider. Available balance is decreased on the transaction amount (with the fee included if available), reserved balance is increased on the transaction amount (with the fee included if available); * **Completed** – transfer is approved by the provider, the current balance is reduced on the transaction amount (with the fee included if available), reserved balance is decreased on the transaction amount (with the fee included if available); * **Failed** – transfer is rejected. The available balance is increased on the transfer amount (with the fee included if available), the reserved balance is decreased on the transaction amount (with the fee included if available); * Date, time – the date and time when the transfer was initiated. Per each transfer, it is possible to look through the detailed information. Besides the information listed in the table, here is an additional detail per each transaction such as: * Remitter and recipient bank account number/IBAN; * Amount – amount without fee; * Amount of fee; * Total amount – amount with fee; * Payment type: incoming or outgoing; *** ### 3. 📦 Orders This tab represented the info about users' orders. The following information is displayed for each order: * Internal order ID * Currency pair * Rate * Sold amount * Status * Date of creation *** ### 4. 💳 Cards This tab represented the info about users' cards. The following information is displayed for each card: * ID * SAN – a unique short account number that contains a 9-digit number * User Name – First, Last name / Company name as a link to individual/corporate * Currency * Type – virtual or physical * Delivered – yes/no (shows "-" if the card is virtual) * Balance * Created at * Updated at * Status *** ## 🏢 Corporates A corporate is a legal entity that is separate and distinct from its owners. Corporate might have a profile in a white label application and be authorized to access and perform various banking activities through it.\ The corporate might be registered to white label web or mobile interface only after creating a profile for an individual. Also as with individual users, it is not possible to create a corporate via the admin panel. The table on page "Corporates" represents the scope of all corporates signed up to the White Label application. Each individual contains the following information: * Company ID; * Company name; * Email; * Verification Status; * Status; * Date of creation; *** #### ✅ Verification status Represents the status of corporate verification via KYB procedure. Applicable values: * **Unconfirmed** – documents for starting KYB procedure verification have not been submitted; * **Pending** – the verification of provided documents is not finished; * **Resubmission Required** – it is needed to resubmit any of provided documents; * **Rejected** – an application is rejected by KYB Service permanently; * **Confirmed** – the KYB procedure is successfully passed, and the corporate user is approved; *** #### 🔐 State The value represents the state of the corporate in the white label system.\ Applicable values: * **Active** – user has access to all functionality; * **Suspended** – functionality "Send money", "Create accounts" are not available. Admin has a right to unsuspend the user; * **Blocked by Admin** – the user is blocked permanently. The user cannot access his corporate profile; * **Closed** – user is closed (done on his/her own). The user cannot access his corporate profile. The profile might be closed only if all his bank account balances are zero and there are no pending transactions. *** #### 🔎 View details Per each corporate, it is possible to look through the detailed information by pressing the \[View] button. Given the details are opened the information there is divided into separate blocks: * General information * Accounts * Orders * Cards *** ### 1. 📑 General information General information is divided into two main sections: **company info** and **legal company info**. * **Company info** represents the information the user entered manually while signed up the corporate. * **Legal company info** displays information that is pulled from the KYB service provider. **KYB Id** serves as a link to an external service provider (SumSub) and enables an admin who has access to this service to look through all the documents/details the applicant submitted for verification. **Part "Individual"** contains information about the individual user who has signed up the company, his unique identifier in the White Label system, and the company position. Except for that info, there is also info about verification status, status, and contract. There is a possibility to search specific corporate by company ID. *** ### 2. 💳 Accounts Here is represented the info about users' bank accounts. An admin has a right just to view those details, there is no possibility to open the account, edit, or close (delete) it. The following information is displayed per each account: * Id – unique account identifier in the white label system; * Account title – the name of the account which is automatically generated, pattern: currency\_account\_order; * Currency – available currencies EUR, GBP, USD, PLN, ETH, USDT, USDC, TRX; * Available balance – the balance resulting from all transactions (including pending status). This is the balance user sees in the app and is available to use; * Reserved balance – the balance resulted from all incomplete (pending) transactions. A total sum of currency on hold for the account (outcoming from the account); * Current balance – the balance created according to transaction that are Completed. * Created at – the date when the account was initiated; * Updated at – the date when information about the account was changed last time: status, balance, created transaction, etc. Editing account details (for mock provider accounts) works the same as for Individuals — see the [Edit account details](#️-edit-account-details) section above for full details on editable fields, validation rules, and shared vs dedicated account holder names. *** ### 3. 💳 Cards This tab represented the info about users' cards. The following information is displayed for each card: * ID * SAN – a unique short account number that contains a 9-digit number * User Name – First, Last name / Company name as a link to individual/corporate * Currency * Type – virtual or physical * Delivered – yes/no (shows "-" if the card is virtual) * Balance * Created at * Updated at * Status *** ## 💰 Transactions Tab **Transactions** of the admin panel is divided into 4 sub-tabs: 1. **All transactions** 2. **Pending in AML** 3. **Failed AML** 4. **Manual Review** Each of them contains a bunch of transactions that are stuck on some specific stage of its life cycle. *** ### 📑 All transactions The represented table on page **"All transactions"** shows the list of all transactions that were made in the White Label application. Each transaction contains the following information: * Transaction ID * Date of creation * Payment method * Payment direction * Remitter * Recipient * Account ID * Amount * Status If you click on the button **"View"**, you will move to the page Transaction details, which we described in the previous parts – Individuals and Corporates. *** ### ⚙️ AML & Manual Review Configuration AML (Anti-Money Laundering) checks and Manual Review are two configurable features that control the transaction approval flow. They can be enabled or disabled independently, giving your compliance team full control over which transactions are processed automatically and which require human approval. #### Configuration levels There are **two levels** of configuration: 1. **System-wide (tenant level)** – applies to all users by default. 2. **Per-user level** – navigate to **Bank Management → Individuals** (or **Corporates**) → select a user → **Configurations** tab. Each setting has two options: **Default** (follows system-wide configuration) or **Skip** (turns it off for this specific user). Per-user configuration has the **highest priority**. For example, if Manual Review for SEPA is ON at system level but a specific user has "Skip Manual Review" for SEPA, that user's SEPA transactions will NOT go to Manual Review. #### AML Check When enabled, every transaction is forwarded to **SumSub** for AML monitoring. SumSub evaluates the transaction and assigns a risk score, resulting in one of three statuses: | AML Status | Meaning | | ----------------- | ---------------------------------------------------------- | | **AML Confirmed** | Passed — proceeds to next step (Manual Review or provider) | | **AML Failed** | Rejected — will not be forwarded to the provider | | **AML Pending** | Requires additional review on the SumSub side | #### Manual Review When enabled, transactions appear in the **Transactions → Manual Review** tab where an admin must **Approve** or **Reject** each one before it reaches the banking provider. Supported payment methods: Internal (outgoing only), SEPA, SEPA Instant, Faster Payment, SWIFT. * **Approve** → transaction is forwarded to the banking provider. The system records who approved and when. * **Reject** → transaction fails and is NOT sent to the provider. The user's reserved balance is rolled back. When you switch Manual Review OFF, any transactions already in the queue can still be approved or rejected — they don't disappear. #### Per-user skip When setting a user to "Skip Manual Review," you must select which payment methods to skip (Internal, SEPA, SEPA Instant, SWIFT, UK Faster Payment). At least one payment method must be selected. #### Transaction flow summary | AML Check | Manual Review | What happens | | --------- | ------------- | ----------------------------------------------------------------------------------------------- | | OFF | OFF | Transaction goes directly to the provider | | ON | OFF | Transaction goes through SumSub. AML Confirmed → provider. AML Failed → fails | | OFF | ON | Transaction skips AML, goes to Manual Review queue | | ON | ON | Transaction goes through SumSub first, then Manual Review queue. Admin makes the final decision | *** ### 🛡️ Pending in AML AML stands for **Anti-Money Laundering**. It is a set of regulations, policies, and procedures implemented by financial institutions and governments to detect and prevent the illegal process of making illegally obtained money appear legal or "clean." The purpose of AML measures is to combat money laundering by identifying suspicious transactions and activities, reporting them to the relevant authorities, and preventing the integration of illicit funds into the legitimate financial system. Currently, the White Label platform uses 3rd party provider – **SumSub** for AML monitoring. Sumsub's Transaction Monitoring offers real-time fraud protection for all kinds of businesses. Each transaction initiated by the end users within the White Label Client application is forwarded to the 3rd party provider for AML monitoring. As a result of the performed check the risk score is assigned to the transaction. Based on the risk score the transaction may have assigned appropriate AML status: **AML confirmed**, **AML failed** or **AML pending**.\ Admin can view all scope of pending in AML transactions moved through the system on the tab **Pending in AML**. The table with transactions contains the following data: * Transaction Id – unique transaction identifier in the white label system * Transaction date – the date when the transaction was initiated * Payment method (7 payment methods available for now: "Internal transfers", "Faster Payment", "SEPA", "SEPA – Instant", "SWIFT", "Arbitrum", and "Ethereum") * Payment type: outgoing or incoming * Remitter (first and last name/company name in case of business users) * Recipient (first and last name/company name in case of business users) * Total Amount (amount + fee) * AML status * Status * Risk score (from 3rd party provider) * A link to 3rd party provider SumSub for this particular transaction * \[View] button Given any member of the Clients' admin team press on the **SumSub link** then it redirects to the SumSub page with an appropriate transaction. All transactions that have the status **"AML pending"** in the admin panel have the status **"Require action"** in SumSub so they are on hold and require action from the Clients' management/admin team members. The basic actions that may be performed are: * **Approval** – then after that it can be sent to the BaaS provider. * **Rejection** – otherwise, if it is rejected it would not be sent to the BaaS provider and become failed right after the AML check. *** ### ❌ Failed AML This tab was created specially for the compliance department and their convenience. All transactions failed due to AML reasons, you can see on this tab. Here is the special column called **"Status"** that has two values: * **Failed** – that means that the transaction failed and didn't return * **Returned** – that means that you already returned this transaction to the remitter Additionally, to returning the transaction, you need to provide the transaction ID or Hash in case of crypto. *** ### 👀 Manual review A **manual review** is an additional option granted to the Clients' admin team to take control of the end users activity within the system examining specific transactions for potential risks, compliance issues, or suspicious activities. An admin has a right to **switch on/off** the possibility of manual reviewing of transactions. The manual review option works bearing in mind different transaction flows: 1. **Flow with AML check on 3rd party side (currently SumSub)** 2. **Flow without AML check** *** ##### Flow 1: With AML check Given an admin has switched **ON** the manual review option when the transaction passed the AML check (on SumSub) then it should appear in the list of transactions for manual review – tab **Manual review**. The table with transactions contains the info as follows: * Transaction Id – unique transaction identifier in the white label system * Transaction date – the date when the transaction was initiated * Payment method (4 payment methods available for now: "Internal transfer", "Faster Payment", "SEPA" and "SWIFT") * Payment type: outgoing * Remitter (first and last name/company name in case of business users) * Recipient (first and last name/company name in case of business users) * Total Amount (amount + fee) * Status * AML status * Risk score (from SumSub) * \[Approve] and \[Reject] buttons * \[View] button **AML status** – the value represents the status of the transaction after the AML check. Possible values: * AML confirmed – transaction successfully passed AML check * AML failed – transaction did not pass AML check and is rejected so it would not be forwarded to the BaaS provider * AML pending – transaction requires an additional manual check on the SumSub side If the member of the Clients' admin team **approves** the transaction that is on the manual review it will be forwarded to the BaaS provider.\ If the member of the Clients' admin team **rejects** the transaction that is on the manual review it will not be forwarded to the BaaS provider and become failed. Given an admin has switched **OFF** the manual review option when the transaction passed the AML check (on SumSub) then it should **NOT appear** in the list of transactions for manual review but should be forwarded to the provider (if AML confirmed) or should NOT be forwarded to the provider (if AML failed). *** ##### Flow 2: Without AML check The flow without an AML check just skips the forwarding transaction to SumSub. * If manual review is **ON**, then after initiating the transaction by the end user it appears in the admin panel, tab **Transactions / Manual review**. Approve and reject options work as in Flow 1. * If manual review is **OFF**, then right after initiating the transaction by the end user it goes to the BaaS provider. *** ### 📤 Transaction Export Admins can export the transaction list from the Backoffice as a **CSV file**. The export feature is available on the **Transactions** page. #### How to export 1. Navigate to the **Transactions** page. 2. Optionally, apply filters (date range, payment method, status, currency, etc.) to limit the data set. 3. Click the **"Export data"** button (changes to "Export filtered data" when filters are active). 4. A toggle **"Include applied filters in export"** allows you to include or exclude your active filters from the export. 5. A pop-up confirms that the file is being generated: *"The exported transaction file is currently being generated. The process may take some time."* 6. Click **"Move to Export page"** to track progress, or **"Continue"** to stay on the current page. #### Export page The export page is located at **Administration → Export**. It shows all generated export files in a table: * **File name** — format: `Transactions_Export_%timestamp%.csv` * **Export ID** * **Type** (e.g. Transactions) * **Created** (date/time) * **Completed** (date/time) * **Progress** (e.g. 10%, 53%, 100%) * **Status** — Pending, In process, Completed, or Error * **Download button** — active once the export is completed #### CSV file contents The exported CSV includes a **header** with applied filters and generation timestamp (UTC), followed by the transaction data. Each row contains the following fields (when available): **Core transaction data:** Transaction ID, Created at (UTC), Payment method/network, Fee type, Payment direction, Amount, Currency, Amount of fee, Total amount, FX markup revenue, Account ID, Account provider, Status, Reference, Purpose, Description, Provider, SumSub applicant ID. **Remitter details:** Name (first/last or corporate), Type, IBAN, BIC/SWIFT, Account number, Intermediary bank BIC/SWIFT, Sort code, Transit number, Institution number, Routing number, Wallet address, Bank name, Bank country, Bank address, Country, City, Address line, Post code. **Recipient details:** Name (first/last or corporate), IBAN, Account number, Sort code, BIC/SWIFT, Wallet address, Bank name, Bank country, Bank address, Type, Country, City, Address line, Post code, Intermediary bank BIC/SWIFT, Intermediary bank account number, Intermediary bank name, Intermediary bank address, Intermediary bank country, Transit number, Institution number, Routing number. **Card data (if applicable):** Card type, Card masked PAN, Card title. **Exchange data (if applicable):** Order ID, Currency pair, On-chain transaction ID. Use the filter before exporting to narrow down your data set. For large tenants, this significantly reduces export time and file size. *** ### 💰 Incoming Transfer Our system includes a **BaaS provider simulator** that replicates the core functionality of a real BaaS provider. We call this simulator the **Mock Provider**.\ As an admin, you can manually create incoming **SEPA**, **SWIFT**, **SEPA INSTANT**, **UK Faster Payments**, **UAE Local**, or **Canadian Local** transactions. At the top of the **Transactions** page, click **"Create transaction"**.\ A modal window will appear with the following fields: **Transfer Details** * **Transfer type** – Incoming transfer * **Payment method** – SEPA, SWIFT, SEPA INSTANT, UK FP, UAE Local, Canadian Local **General Info** * **Account ID** – Mandatory, accepts digits only * **IBAN** – Auto-filled by the system based on the Account ID * **BIC/SWIFT** – Auto-filled by the system based on the Account ID * **User name** – Auto-filled by the system based on the Account ID * **Gross amount** * **Currency** – EUR, USD, or GBP * **BaaS provider** – Auto-filled (Mock Provider) * **Reference** **Remitter Details** * **Remitter name** – Mandatory * **IBAN or account number** – Optional * **BIC/SWIFT or Sort code** – Optional * **Remitter address** – Street line 1, line 2, city, post code, country (optional) * **Remitter bank name** – Optional * **Remitter bank country** – Optional * **Remitter bank address** – Optional Create Incoming Transaction *** ### ⚙️ Charge Fee In addition to creating incoming transactions, admins can also **apply account-related fees** such as account opening or monthly maintenance fees directly through the system. On the **Transactions** page, select **Create transaction**, then choose the **Transfer type – Fee charge** option.\ This allows you to manually debit a specific amount from a user's account. **General Info** * **Search by internal account ID** – Mandatory * **User name** – Auto-filled * **IBAN / Account number** – Auto-filled * **Currency** – Mandatory * **Available balance** – Auto-filled for reference * **Amount** – Mandatory Once all required fields are filled, click **Create** to apply the fee. Create Fee Charge Transaction > 💡 **Notes:** > > * You can manage fees manually from the Back Office under **Bank Management → Transactions**. > * Monthly fee automation is planned for release soon, allowing recurring charges to be applied automatically. ## 💳 Cards Each user can create a card for their account in our system.\ The represented table on page **"Cards"** shows the list of all cards that were created in the White Label application. It contains two pages: * **All Cards** * **KYC Failed** The main difference between these two pages is that **KYC Failed** shows only cards that have some issues with KYC onboarding. Each card contains the following information: * **ID** * **SAN** – a unique short account number that contains a 9-digit number * **User Name** – First, Last name / Company name as a link to individual/corporate * **Currency** * **Type** – virtual or physical * **Delivered** – yes/no (shows "-" if the card is virtual) * **Balance** * **Created at** * **Updated at** * **Status** * *KYC Status* – available only on the KYC Failed page *** ### 🔎 View Details Per each card, it is possible to look through the detailed information by pressing the **\[View]** button.\ When details are opened, the information is divided into **2 separate blocks**: 1. **General information** 2. **Operations** *** #### 📑 General Information General information is divided into two main sections: * **Card information** – shows the same data as on the page "Cards" plus an additional field: *Masked card number* * **Cardholder information** – displays information about the user, pulled from the KYC service Additionally, this block contains **State** and **KYC status**. *** ##### 🛡️ KYC Statuses | **Status** | **Explanation** | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Unconfirmed** | Technical default status when a card is created on our side but the KYC upload process hasn't started yet. | | **Initiated** | The KYC upload started. | | **Pending** | Once a card is created, the KYC documents are automatically sent to Intercash. Once it is done, the KYC status is pending. | | **Submission failed** | The KYC upload failed (documents might be invalid, absent, or in the wrong format). In this case, the KYC status will change to "submit\_failed". The back-office admin can resolve this issue manually by uploading documents via email. If Intercash does not approve KYC anyway, the back-office admin clicks **Reject** and both card status and KYC status become **Rejected**. | | **Resubmission requested** | If KYC was rejected by Intercash, the card remains in pending status but shows **"Resubmission requested"** with rejection reason. The admin needs to contact Intercash manually ([clientservices@intercash.com](mailto:clientservices@intercash.com)) and resubmit the documents. | | **Rejected** | If Intercash does not approve and the admin understands it is a final decision – the back-office admin clicks **Reject**, and the card status becomes **Rejected** (final). | | **Confirmed** | If Intercash approves, the status will change to **Approved** automatically. | *** #### 💳 Operations This block represents the information about operations made with the chosen card. ⚠️ An admin has the right only to **view** these details.\ There is **no possibility** to cancel or change an operation. The following information is displayed per each operation: * **ID** * **Time/Date** * **Description** – Card top-up / merchant name / ATM name * **Category** – defined according to MCC code * **Amount** * **Operation type** – completed / authorization attempt *** ##### 🔎 Operation Details Per each operation, it is possible to view detailed information by pressing the **\[View]** button.\ When details are opened, the information is divided into **3 separate blocks**: 1. **Operation information** 2. **Operation type** 3. **Operation status** # BCB Group Source: https://docs.finhost.io/bcb Banking for crypto businesses via BCB, abstracted by Finhost. ## Overview Finhost can connect to **BCB Group** for fiat rails. Your app continues to call the unified **Client API**. ## Capabilities (typical) * GBP/EUR accounts for corporate use * **Faster Payments / SEPA** connectivity * Crypto‑friendly treasury and settlement workflows * Statements & inward/outward payment support *** # Branding Source: https://docs.finhost.io/branding Customize Web and Mobile apps to match your brand. # Branding Our platform is fully customizable to match your brand identity across **Web** and **Mobile** applications. This page covers what we update by default and how to request a fully custom UI. ## What we update Replace default typography with your brand fonts. Apply your primary and secondary palette to UI elements. Use correct logo variants on light and dark backgrounds. Align iconography to your preferred icon set and style. ## Custom design option We can also produce a **bespoke design** for Web and Mobile in collaboration with our designer—beyond font, color, logo, and icon swaps. ## Helpful links Technical configuration for your deployment. What to prepare ahead of branding work. ## Asset checklist (optional) * **Logos:** SVG and PNG (light/dark variants) * **Fonts:** Web license files (WOFF2/WOFF) * **Colors:** Brand hex values (primary/secondary) * **Icons:** SVG set or icon font (if applicable) # BVNK Source: https://docs.finhost.io/bvnk Payments/crypto services — integration in progress. ## Overview **BVNK** integration is in progress. Your app will continue to use the **Client API**; Finhost routes to BVNK where configured. ## Anticipated capabilities * Multi‑currency accounts and settlements * EUR/GBP payments (SEPA/FPS) where supported * Crypto ↔ fiat conversion rails (tenant‑dependent) * Statements and reconciliation aids *** # ClearBank Source: https://docs.finhost.io/clearbank UK clearing and accounts — integration in progress. ## Overview **ClearBank** integration is under development. Finhost will expose ClearBank‑backed features through the standard **Client API**. ## Anticipated capabilities * **GBP accounts** * **MCCY (multi-currency) accounts** (tenant-dependent) * **Faster Payments** (and CHAPS where applicable) * Confirmation of Payee (CoP) checks * Statements and inward/outward payments *** # Auth & Authorization Source: https://docs.finhost.io/custom-fe-app-auth Learn how to get started with our API. ## Cognito Authorization Required to have: * User Pool Region (example: `eu-central-1`) * User Pool ID (example: `eu_central_111111`) * User Pool Web Client ID (example: `1234qwerty7890asdfg`) * UsernameID (example: `e7c6ae40-ca66-4d2a-8d37-337d3e8c92bb`) - is required to generate username (uuid v5) based on UsernameID and email. Ask LabelRails team for access. (User Pool Region, User Pool ID, User Pool Web Client ID - will be provided by LabelRails tech team) Install AWS Amplify and connect Auth API according to the documentation: [Amplify Auth API](https://docs.amplify.aws/react/build-a-backend/auth/connect-your-frontend/). You can either use a custom UI by connecting Auth API: [Custom UI](https://docs.amplify.aws/react/build-a-backend/auth/connect-your-frontend/sign-up/) or Amplify Authenticator Component: [Authenticator Component](https://docs.amplify.aws/react/build-a-backend/auth/connect-your-frontend/using-the-authenticator/). ## API Usage Required to have: * API host URL (will be provided by LabelRails tech team). If you want to use AWS Amplify to fetch data, which we recommend, then follow this documentation: [REST API with AWS Amplify](https://docs.amplify.aws/react/build-a-backend/add-aws-services/rest-api/existing-resources/). You can also use any other tool to fetch data. To use authorization via Cognito User Pool, you must retrieve the user idToken and send it in headers. ``` import { fetchAuthSession } from 'aws-amplify/auth' const session = await fetchAuthSession(); const token = session.tokens?.idToken; const headers = { Authorization: token }; ``` # Before start Source: https://docs.finhost.io/custom-fe-app-before-start Basic overview To begin working efficiently with our API, please read the instructions carefully. Before you start, please contact the Finhost team to obtain all necessary keys. Please note that we use AWS Cognito with Amplify for authentication and authorization. Ensure you are familiar with this service before starting. Once everything is ready, make sure to implement the onboarding flow in the following order: 1. Sign up (Amplify AWS Cognito) 2. Confirm sign up 3. Initiate new user: [POST /client](/api-reference/client/initiate-a-new-client-client-api) 4. Accept contract (fee plan): [POST /v2/clients/contract-accept](/api-reference/clients/accept-contract-for-client) 5. Initiate KYC process (SumSub SDK): [GET /v2/clients/kyc-access-token](/api-reference/clients/get-kyc-access-token-for-client) Please note, you can create a corporate account only after an individual account is created and virified. 
 # KYC implementation Source: https://docs.finhost.io/custom-fe-app-kyc KYC configurations and SumSub SDK To integrate with SumSub SDK, you must follow this documentation: [SumSub Web SDK](https://docs.sumsub.com/docs/get-started-with-web-sdk#react-integration). Access key is generated by routes [GET /v1/kyc/access-token](/api-reference/clients/get-kyc-access-token-for-client) and [GET /v1/kyb/access-token/](/api-reference/companies/get-kyb-access-token-for-company). To customize the theme for SumSub, please follow this guide: [SumSub Customization](https://docs.sumsub.com/docs/set-customization). # Sign Up, Sign In, API Source: https://docs.finhost.io/custom-fe-app-sign-up-in ### Sign-Up You need to generate a username (uuid v5) on the front end based on UsernameID and email, and send the email as an attribute. ``` import { v5 as uuidv5 } from 'uuid'; import { signUp as cognitoSignUp } from 'aws-amplify/auth'; const getUserIdByEmail = (email: string) => uuidv5(email, usernameID); const signUp = async ({ email, password }) => { const response = await cognitoSignUp({ username: getUserIdByEmail(email), password: password, options: { userAttributes: { email: email } } }); return response; }; ``` ### Confirm Sign-Up Since the username is a uuid v5, to confirm sign-up we must send this username by generating it on the front end based on email. ``` import { v5 as uuidv5 } from 'uuid'; import { confirmSignUp as cognitoConfirmSignUp } from 'aws-amplify/auth'; const getUserIdByEmail = (email: string) => uuidv5(email, usernameID); const confirmSignUp = async ({ email, code }) => { const response = await cognitoConfirmSignUp({ username: getUserIdByEmail(email), confirmationCode: code }); return response; }; ``` ### Sign-In To sign in, you can send either a phone number, email, or a username: [Sign-In](https://docs.amplify.aws/react/build-a-backend/auth/connect-your-frontend/sign-in/). However, be aware that during sign-up, a user can avoid confirming their email and leave the app. When they try to sign in, you cannot send the email since it is unconfirmed. The solution is to send a generated username or phone number. ``` const username = selectedType === 'phone' ? phoneNumber : getUserIdByEmail(email); const response = await signIn({ username, password: password }); ``` ### Forgot Password Similar to sign-in, you can send a phone number or email: [Reset Password](https://docs.amplify.aws/react/build-a-backend/auth/manage-users/manage-passwords/#reset-password). If the user is unconfirmed, they must first confirm their account and then request a password recovery code. This is possible only when sending a generated username and receiving a corresponding error that the user is unconfirmed. ### Phone Number To add a phone number, the user must first confirm their email. After which, they are authenticated and able to use our API. The [POST /client](/api-reference/client/initiate-a-new-client-client-api) route is used to create a user in our database. Alongside the phone number, it will also trigger the Cognito flow to confirm the phone number attribute and send a confirmation code via SMS. After a successful triggering of the [POST /client](/api-reference/client/initiate-a-new-client-client-api) route, we must verify the attribute: [Verify User Attribute](https://docs.amplify.aws/react/build-a-backend/auth/connect-your-frontend/manage-user-attributes/#verify-user-attribute) or request another code: [Send Verification Code](https://docs.amplify.aws/react/build-a-backend/auth/connect-your-frontend/manage-user-attributes/#send-user-attribute-verification-code). If a wrong number was entered, it is possible to change it by using the [PATCH /client](/api-reference/client/update-client-info-client-api-indevelopnent) route and then confirm it. # Fireblocks Source: https://docs.finhost.io/fireblocks Crypto custody & transfers through Finhost crypto features. ## Overview Finhost uses **Fireblocks** for custody/crypto movements. Client apps use the **Client API** (crypto namespace) — not Fireblocks directly. ## Capabilities (typical) * Custody wallets (MPC) with policy engine * Address whitelisting & network routing * Transfers between internal/external wallets * Deposit address management and confirmation events *** # Fiat Republic Source: https://docs.finhost.io/fr Third‑party payments & virtual IBANs — integration in progress. ## Overview **Fiat Republic** integration is under active development. Once enabled for your tenant, access will be through the **Client API** as usual. ## Anticipated capabilities * EUR/GBP **virtual/dedicated IBANs** * **SEPA / Faster Payments** where supported * Beneficiary management & statements * Compliance checks aligned with partner banks *** # Fuse Source: https://docs.finhost.io/fuse Payments connectivity via Fuse, abstracted behind Finhost Client API. ## Overview Fuse connects payment rails. Your app uses **/v2/transfer** and related endpoints; Finhost orchestrates Fuse behind the scenes. ## Capabilities * Pay‑in/pay‑out orchestration across connected rails * Beneficiary validation & payment status updates * Reconciliation aids (payment references) * Basic FX routing where available *** # IFX Payments Source: https://docs.finhost.io/ifx Payments & FX settlement handled by Finhost using IFX Payments. ## Overview Finhost may route fiat payments and FX through **IFX Payments**. The integration remains **Client → Finhost**. ## Capabilities (typical) * EUR/GBP/other **fiat rails** * **SWIFT/SEPA** transfers * **Spot FX** and conversions (per tenant enablement) * Statements and balances ## Notes * FX availability depends on your tenant configuration. *** # Introduction Source: https://docs.finhost.io/index Start here—overview of the Finhost white‑label banking platform, docs map, and setup checklist. This is the high‑level entry point to your **Finhost** documentation. It orients product teams, developers, and back‑office admins, then points you to the right deep‑dives. ## What is Finhost? **Finhost** is a white‑label digital banking platform that ships: * **Customizable front‑end apps** (web & mobile) that connect to your Core via APIs * A secure **Auth layer** (Cognito) and app‑side session management * **KYC/KYB** flows integrated with providers (e.g., Sumsub) * An **Admin Back‑Office** for operations, compliance, and support * Integrations with **EMIs/PSPs/Custodians** (e.g., OpenPayd, BCB, Fireblocks, Intercash, Kraken) to issue accounts, move money, and manage crypto rails > Use this page to understand the parts and jump to the section you need. *** ## Quick links Global settings & branding hooks that shape your white‑label instance. Colors, logos, and UI tokens to match your brand. Local env, dependencies, and how the front‑end talks to Core. API documentation, Auth & Authorization How admins sign in (2FA), navigate, and what they can see. ### Provider integrations KYC/KYB & Transaction Monitoring. IBANs & fiat rails. Payments connectivity. Payments & FX. Banking for crypto businesses. Crypto custody & transfers. Card issuing. Crypto liquidity & accounts. Coming soon. Coming soon. Coming soon. *** ## How the pieces fit together 1. **Auth & Sessions** → The app authenticates users against Cognito and stores tokens client‑side for secure API calls. 2. **Signup flow** → Users register, confirm, and initialize their profile in Core. Contracts (fees/limits) are accepted as part of onboarding. 3. **KYC/KYB** → The app requests a provider access token and opens the Sumsub Web SDK with your theme configuration. On result callbacks, the app updates user state. 4. **Backoffice** → Admins sign in with 2FA and manage users, accounts, transactions, and cards; compliance can monitor AML and manual review queues. 5. **Reports** → Daily‑computed KPIs with on‑demand refresh for balances, plus onboarding and reconciliation views. 6. **Providers** → Operational calls (IBAN issuing, payments, custody, cards) are routed via configured providers per currency/rail. Building a custom app? Start with **Before start**, then **Auth**, then **Sign Up/Sign In**, and finally **KYC**. Operators should begin with **Backoffice › Introduction**, then **Reports** and **Bank management**. *** ## Support & feedback If anything is unclear or missing, leave a note in your docs repo or contact the Finhost team. The docs are evolving—your feedback helps us prioritize the next updates. # Intercash Source: https://docs.finhost.io/intercash Card issuing via Finhost; provider is Intercash. ## Overview **Intercash** powers card issuing. The **Client API** exposes unified card/account flows; Intercash is configured provider‑side in Finhost. ## Capabilities (typical) * **Physical & virtual** card issuing (prepaid/debit per program) * BIN sponsorship & 3‑D Secure * Spend controls, limits, and card lifecycle ops * Clearing/settlement via linked accounts Exact card endpoints vary by tenant enablement. Your Finhost contact will enable the card module and share the available API paths. *** # Introduction Source: https://docs.finhost.io/introduction This page focuses on the **Backoffice** (admin panel) used by your team (ops, compliance, support, finance). If you’re integrating the API, see the **API Integration — Introduction**. ## What is the Backoffice? A secure, web-based admin tool for managing **users, accounts, cards, transactions, reporting, and compliance workflows** in your white‑label banking stack. Dashboards, onboarding, reconciliation. Individuals, corporates, transactions, cards. Admins, contracts, revenue accounts, requests. *** ## Access & invitations Backoffice **sign‑up is restricted**. Admin users are **created by the Finhost team** or by existing admins. There is **no public self‑registration** form. **To request initial access**, provide to Finhost: * First name * Last name * Email (work) You’ll receive an **invitation email** with your **username** and a **temporary password**. After first sign‑in you’ll be prompted to change it. Once the first admin is created, that admin can **invite additional admins** directly from **Administration → Administrators** (permissions apply). *** ## Sign in (with 2FA) 1. Open your Backoffice URL. 2. Enter your **email** and **temporary password** from the invitation. 3. Set up **two‑factor authentication (2FA)** with **Google Authenticator**. 4. Use the **one‑time code** to complete login. If you change devices, ask another admin to temporarily disable 2FA for your user, then set it up again on the new device. *** ## Navigation primer Use the left navigation to reach the main areas: * **Reports** → **Dashboard**, **Onboarding**, **Reconciliation** * **Bank management** → **Individuals**, **Corporates**, **Transactions**, **Cards** * **Administration** → **Administrators**, **Contracts**, **Revenue accounts**, **Requests** Use the **search** (look for the search bar or **⌘K**) to quickly jump to entities by name, email, or ID. *** ## Role‑based quick starts Review KYC/KYB states, run manual checks, monitor high‑risk transactions, and approve/decline **Requests**. Create accounts, view balances & bank details, troubleshoot failed payouts, and reconcile **Reports** daily. Locate users, reset access (with policy), view recent transactions, and raise internal **Requests** to compliance. Track KPI dashboards, export onboarding & reconciliation datasets, and audit **Revenue accounts**. *** ## Daily checklist * [ ] Review **Dashboard** KPIs & alerts * [ ] Process pending **Requests** (limits, accounts, compliance flags) * [ ] Clear today’s **Onboarding** queue * [ ] Reconcile **incoming/outgoing** payments * [ ] Sample check of **high‑value transactions** * [ ] Audit recent **admin actions** (spot check) *** # Kraken Source: https://docs.finhost.io/kraken Crypto liquidity via Finhost crypto features backed by Kraken. ## Overview Finhost may source crypto liquidity via **Kraken**. Your app uses the **Client API** (crypto namespace) for orders and payouts. ## Capabilities (typical) * Spot market liquidity for major assets * Market & limit order support * Funding/payout flows via Finhost treasury * Status webhooks/events handled provider‑side *** # OpenPayd Source: https://docs.finhost.io/openpayd IBAN issuing & payments routed via OpenPayd through Finhost. ## Overview OpenPayd is used by Finhost to provide **IBANs and payments**. You only call unified **Client API** endpoints; Finhost selects OpenPayd as the provider. ## Capabilities (typical) * EUR/GBP **IBAN issuing** (virtual/dedicated per configuration) * **SEPA / SWIFT** payments; **Faster Payments** where enabled * Incoming/outgoing transfers & beneficiary management * Statements and balance retrieval * FX conversion (where configured) *** # Reports Source: https://docs.finhost.io/reports-dashboard The Reports provides a consolidated view of key business metrics for White Label applications. It is designed primarily for the **management team** of clients, offering insight into **financial performance, onboarding progress, and reconciliation data**. Reports are divided into three subsections: * **Dashboard** * **Onboarding** * **Reconciliation** *** ## 1. Data Storage & Updates To ensure fast retrieval and accuracy: * Metrics are **calculated daily** for the previous day (UTC 0). * Current-day metrics are updated **in real-time** when requested by the Core Admin. * Data must always be up-to-date at the moment of the request. * Historical balances are available only from the date this feature is released. *** ## 2. Dashboard The **Dashboard** provides high-level financial and operational metrics. ### Filters * **Period**: last 7 days, last 30 days (default), all time, or custom date picker (from–to). * **User type**: all (default), individual, corporate. ### Metrics #### Balances * Shows the **sum of all balances** across the system (Available, Reserved, Current). * Displayed **per provider** and **per currency**. * Balances update in real time when dashboard is opened. * Balances are also recorded daily at 00:00:00 for historical reporting. * Balances include **revenue accounts** as well. ℹ️ **Info text:** * *Available Balance*: funds currently accessible for use. * *Reserved Balance*: pending outgoing + pending incoming transactions. * *Current Balance*: balance from completed transactions only. * All balances are shown as of the latest date in the selected filter range. *** #### Turnover (Total Transaction Volume) * Cumulative flow of all **external transfers**. * Shown per currency: EUR, GBP, USD, BTC, ETH, USDT, USDC. #### Quantity of Transactions * Total number of transactions through user accounts. * Split into **incoming** and **outgoing**. *** #### Volume by Payment Method * Money flow by payment method and currency. * Methods: Internal, SEPA, SEPA Instant, SWIFT, UKFP, Crypto networks, Currency Exchange. * Split into **incoming** and **outgoing**. #### Quantity by Payment Method * Total number of transactions by method. * Includes internal, fiat rails, crypto, card top-up, and currency exchange (orders). * Split into **incoming** and **outgoing**. ℹ️ **Info text:**\ *Only completed transactions are considered.* *** #### Currency Exchange Volume * Total amount of currency bought and sold. * Tracked per currency: EUR, BTC, ETH, USDT, USDC. *** #### Operations by Type * Shows distribution (%) of different payment methods. * Formula: `(Transactions of type / Total transactions) * 100%` * Exchange = calculated by orders, not transactions. *** #### Revenue * Total fees collected by currency:\ EUR, GBP, USD, PLN, CAD, BTC, ETH, USDT, USDC, TRUMP, TRX. #### Fees by Operations * Fees collected per payment method, split by incoming/outgoing. * Includes: SEPA, SEPA Instant, SWIFT, UKFP, Crypto networks, Currency Exchange. *** #### AML Success Rate * Share of transactions passing AML checks. * Formula: `(Transactions with AML confirmed / Total transactions) * 100%`. *** #### Active Accounts * Number of accounts active in the selected period. * **Fiat account** = existed during the period with valid IBAN/account number. * **Crypto account** = had at least one transaction during the period. ℹ️ **Info text:** * *Active fiat accounts = accounts with IBAN/account number.* * *Active crypto accounts = accounts with at least one transaction.* *** ## 3. Onboarding (UNDER CONSTRUCTIONS) The **Onboarding** subsection tracks user progress through KYC/KYB. ### Filters * **User type**: all (default), individual, corporate. ### Metrics #### Total Group * **Total Quantity of Users**: fully verified users with contract assigned. * **Active Users**: non-suspended users with at least one transaction in the last 30 days. #### KYC/KYB Procedure * **Not Started**: users with status `unconfirmed`. * **Initiated**: users who opened KYC/KYB but did not complete. * **Pending**: documents submitted, waiting for review. * **Resubmission**: additional documents requested. * **Approved**: fully verified. * **Rejected**: permanently rejected. #### Applicants by Country * **Leads**: users with unconfirmed status. * **In Progress Applicants**: initiated, pending, or resubmission. * **Rejected Applicants**: rejected. * **Approved Applicants**: confirmed. *** ## 4. Reconciliation The **Reconciliation tab** compares internal customer funds data with the actual balances reported by custody providers.\ It helps Admins ensure accuracy of funds and quickly detect mismatches between internal and provider records. ### Data Displayed For each **currency + custody provider** pair, the table shows: * **Currency** * **Custody Provider** (e.g., bank, PSP, or crypto custodian) * **Last Updated** (timestamp of last data sync for customer funds) * **Current Balance (customer funds)** → based on completed transactions * **Reserved Balance (customer funds)** → pending incoming + pending outgoing transactions * **Available Balance (customer funds)** → immediately spendable balance * **Revenue Balance (own funds)** → system’s own revenue accounts for that currency * **Actual Balance (provider – real time)** → latest balance fetched directly from provider ### Behavior * **Refresh button** allows Admins to fetch balances in real-time from custody providers. * Balances are displayed per **currency** and **provider** (e.g., EUR/OpenPayd, USDT/Kraken). * Revenue accounts are included to show system-owned funds separately from customer funds. * Discrepancies between **customer funds balances** and **provider balances** indicate reconciliation issues. ### Example Table # Sumsub Source: https://docs.finhost.io/sumsub KYC/KYB provider integration via Finhost Client API. ## Overview Finhost uses **Sumsub** for KYC/KYB. Your app never talks to Sumsub directly; you call the **Client API**, and open Sumsub's Web SDK using a Finhost‑issued token. ## Capabilities (when enabled) * Identity verification (documents + selfie/liveness) * KYB (company verification, UBOs) * AML screening (PEP/sanctions/watchlists) * Proof‑of‑address, questionnaire support * Ongoing monitoring & risk statuses *** # System Configurations Source: https://docs.finhost.io/system-config > **Scope**\ > This section describes how to configure third-party integrations required for authentication and messaging services — including WhatsApp OTP via Meta and Google reCAPTCHA API keys. *** ## ⚙️ System Config Overview Before deploying your production environment, ensure that all third-party configurations are properly set up.\ Each integration below has a specific purpose: | Integration | Purpose | | -------------------- | ----------------------------------------------------------- | | **WhatsApp (Meta)** | Used for sending OTP codes and user notifications. | | **Google reCAPTCHA** | Used for protecting login and registration forms from bots. | *** ## 💬 WhatsApp Configurations ### 🧩 Step 1. Create a Meta (Facebook) Developer App Go to [Meta for Developers](https://developers.facebook.com/apps)\ Click **Create App** → on the “Add Use Cases” screen scroll down and select **Other** → choose **Business** as the app type → **Next**.\ Fill in the following: * **App Name:** e.g. `Your Project Name WhatsApp` * **Contact Email:** your business email * **Business Account:** select your company (or create one)\ Then click **Create App** ✅ You’ll now see your **App Dashboard**. *** ### 💬 Step 2. Add the WhatsApp Product In the left menu, scroll to **Add Product** → find **WhatsApp** → click **Set Up**.\ ✅ The **WhatsApp Business Platform** is now linked to your app. *** ### ☎️ Step 3. Connect Your Business Phone Number Open **App Dashboard → Products → WhatsApp → Getting Started**.\ Click **Add phone number** and fill in: * **Display Name:** the name users will see (e.g. `Your Project Name`) * **Business Name**, **Website**, and **Email** * Enter your **Phone Number** (must not already be linked to any WhatsApp account) * Verify with the 6-digit code sent to your phone ✅ Once verified, your number appears under your **WhatsApp Business Account**. *** ### 🏢 Step 4. Confirm Your Business Information Visit [Business Settings](https://business.facebook.com/settings)\ → **Business Info**\ Ensure the following are filled correctly: * Legal Name * Business Address * Business Email * Website URL *(Verification documents are not required yet, but must match your business details.)* *** ### 🔑 Step 5. Create a Permanent Access Token This token allows your backend to send WhatsApp messages through API. **A. Create a System User** Go to **Business Settings → System Users**\ Click **Add → Add System User** * Name: `yourproject_api_user` * Role: `Admin` **B. Assign Permissions and Link App** * Click your new **System User** * Add Assets → Apps → your app → grant Full Control * Add Assets → WhatsApp Accounts → your WhatsApp Account → grant Full Access * Refresh the browser page **C. Generate Token** * Click **Generate New Token** * Choose your **App** * Enable: * `whatsapp_business_management` * `whatsapp_business_messaging` * Enable **Never Expires** * Copy the generated token and store it securely. ✅ This is your **Permanent Access Token**. *** ### 🧾 Step 6. Find Your Account Identifiers Return to your app: **Developers → Your App → WhatsApp → Getting Started**\ Copy: * **WhatsApp Business Account ID** * **Phone Number ID** ✅ Both are required for integration. *** ### 💡 Step 7. Create an OTP Template Go to [Message Templates](https://business.facebook.com/wa/manage/message-templates/)\ Click **Create Template** and choose: * Category: `Authentication` * Type: `Copy Code` * Name: `otp_login` * Language: `English (US)` **Body Example:** `{{1}} is your verification code.` Do not share this code. It expires in 10 minutes. Click **Submit** → wait for **Approved** status.\ ✅ Copy the Template Name and Language Code. *** ### 🧰 Step 8. Share These Details with Developers | Field | Example | Location | | ---------------------- | ------------------- | -------------------------------- | | Phone Number ID | `987654321098765` | App → WhatsApp → Getting Started | | Business Display Name | `Your Project Name` | During number setup | | Sender Phone (E.164) | `+120978282366` | During number setup | | Permanent Access Token | `EAABcdEf...XYZ` | Business Settings → System Users | | Approved Template Name | `otp_login` | WhatsApp Manager | | Template Language Code | `en_US` | WhatsApp Manager | > **Share securely:** Use encrypted email or password manager.