01. Open operation records from customer detail

Customer operation records are usually opened from the customer detail page.

Before reviewing records, confirm the customer name, UID, Email, and organization. Operation records are bound to a specific customer, so staff should confirm the displayed customer identity first to avoid reviewing the wrong account history.

02. Customer behavior records

The system records important customer events according to the currently connected capabilities. Examples include successful login, failed login, App login attempt, order submission, order cancellation, order modification, and other trading-related operations.

Trading behavior records help back-office staff determine whether the customer actually initiated a certain action at a specific time. For example, if a customer reports that they did not submit an order, staff can review operation time, source, device, and related order records together.

03. Manager back-office actions

In addition to client-side behavior, customer operation records can store important Manager actions performed against the customer.

Examples include modifying customer profile data, changing account relationships, adjusting IB ownership, changing customer status, freezing login access, restoring login access, and other customer permission changes.

Back-office operation records help the team confirm who performed what action, on which customer, and at what time. For actions involving account permissions, risk handling, or customer profile changes, operation records are an important basis for follow-up tracing.

04. Filter by time range

The page can narrow operation records by time range, such as today, a specified time period, a recent period, or historical records.

When a customer reports an issue that occurred at a specific time, start with a time filter to reduce unrelated records. For example, if a customer says they could not sign in around 21:00, filter that period first and then review failed login events, permission changes, or system events.

05. Filter by operation type

Records can be filtered by operation type. Common types include all operations, login-related events, trading-related events, customer profile changes, permission changes, and risk-related actions.

Different operation types support different investigation scenarios. Customer service staff handling login issues can start with login and permission records. Trading issues can start with order submission, cancellation, and order-related records.

06. Filter by source

Operation records show the event source. Common sources can include Finger Trader App, Finger Trader iOS, Finger Trader Android, Finger Trader Web, Finger Manager, Manager Console, and automated system tasks.

The source field helps staff determine whether an action was initiated from the customer client, performed by a back-office administrator, or generated automatically by the system.

07. Review IP and device information

When the system can capture related information, operation records can show IP address, device information, client source, and login terminal.

These fields can help identify the environment behind an operation. However, IP and device information are only supporting evidence. Due to mobile networks, proxies, corporate networks, dynamic IPs, and other factors, staff should not identify the actual operator solely by IP address.

08. Risk level

Some operations can display a risk level according to event type or system rules, such as low, medium, or high.

High-risk records help staff quickly identify events that may require further investigation. Examples include consecutive failed logins, sensitive permission changes, and account freeze actions.

Risk level is used to help back-office staff sort and identify events. It does not represent a final risk conclusion.

09. Open record detail

Click View or Detail on a record to inspect the full event context. Depending on the event type, detail can include operation time, operator, customer UID, behavior type, behavior content, source system, IP / device, linked order, permission changes, before / after status, notes, or reason.

For complex issues, use the detail page to confirm the full context rather than relying only on the brief description in the list.

10. Reconstruct an event sequence

When an issue involves multiple consecutive operations, review related records in chronological order.

For example: an administrator turns off customer login access -> the customer attempts to sign in -> the system returns frozen-account status -> Finger Trader rejects the login -> the client shows the frozen-account message.

Combining time, source, and operation content helps reconstruct the full event chain. This is especially useful for login anomalies, permission disputes, customer complaints, and risk-event investigations.

11. Export operation records

Authorized roles can export operation records for the current customer. Exported content is limited by current filters, user role, data permissions, and export permissions.

Exported records can be used for internal review, risk investigation, or other authorized business purposes. Information involving customer behavior, IP, device, and account permissions is sensitive back-office data and should be stored and used according to the institution's internal data-management requirements.

12. Relationship with business data

Customer operation records describe what actions occurred, but they do not replace formal data in the relevant business system.

For example, an operation record may show that a customer submitted an order request. Whether the order was filled, the fill price, and the final order status should still be confirmed in order management and trading records.

Similarly, an operation record may show that an administrator changed customer permissions, but the final current permission state should still be confirmed from the latest customer detail data. Operation records are mainly used to trace the process and reconstruct events, while current business pages confirm the final state.

Usage note

When investigating a customer issue, a recommended workflow is: confirm customer UID -> confirm issue time -> filter operation type -> review source and IP / device -> open record detail -> compare with order data or current account status.

The core value of customer operation records is: record behavior -> reconstruct process -> confirm responsibility chain -> support follow-up handling.

Operation records help operations, customer service, risk, and management teams locate issues faster, but a single operation record should not be used as a final conclusion without checking the related order, account status, and other business data.