Basic troubleshooting approach

A practical investigation usually starts by confirming when the issue happened, which user, account, or system was involved, which module the issue belongs to, which logs apply, what Error Code or Error Message was returned, whether permissions and system configuration are correct, whether external services or third-party systems are working, and whether Request ID or Order ID can be used for deeper tracking.

Keeping accurate time, user, order number, Request ID, and error details significantly improves troubleshooting speed.

Login issues

If a user cannot log in to Finger Manager, check whether the account and password are correct, whether the user account is enabled, whether the user has access to the Organization, whether the source IP is on the whitelist, whether MFA succeeded, whether SSO is normal, whether the Session has expired, and whether consecutive failure limits were triggered.

The recommended investigation entry is Login Logs, which can confirm login time, source IP, device, and specific failure reason.

Permission issues

If a user can log in but cannot see a page or perform an action, check the user's Organization, roles, feature permissions, data permissions, API permissions, module permission, and whether the current feature is enabled.

For example, if the user can open Customer Management but cannot edit customer information, check whether the role has the corresponding Edit or Update permission.

API call failures

If an API request fails, check whether the API Key is valid, API Secret is correct, request signature is correct, API permission is enabled, source IP is in the API whitelist, Endpoint and HTTP Method are correct, request parameters and format are complete, Rate Limit has not been exceeded, and external network connectivity is normal.

The recommended investigation entry is API Logs. Focus on Request ID, HTTP Status, Error Code, Error Message, Source IP, and Response Time.

Notification sending failures

If Push, Email, SMS, or another notification fails, check whether the target users are correct, user contact details are valid, Device Token is valid, Apple APNs and Google FCM configuration is normal, SMTP settings are correct, SMS provider account is normal, API Keys or provider credentials are valid, third-party services are operating, and message content complies with provider rules.

The recommended investigation entry is Notification Sending Records. Confirm Channel, Provider, Message ID, Status, Error Code, and Error Message.

Order exceptions

If order submission fails, is rejected, or does not return status normally, investigate according to the order-processing flow: user submits order, parameter validation, risk check, order routing, Broker / LP / OMS, execution system, and order report.

Check whether the Ticker is correct, the product is tradable, the market is open, the order type is supported, quantity meets requirements, price precision is correct, account status is normal, buying power is sufficient, risk controls rejected the order, routing is normal, Broker or LP returned a reject, and FIX Session is normal.

Recommended entries include Order Error Records, API Logs, and related trading logs.

Order status mismatch

If the order status shown on the frontend differs from the external broker or trading system, check Order ID, Client Order ID, FIX ClOrdID, ExecID, latest order-report time, whether the external system returned an Execution Report, whether the report was parsed correctly, and whether network delay or timeout exists.

When FIX is used, combine the FIX Session and Execution Report for investigation.

Page data anomalies

If a back-office page shows stale data, inconsistent statistics, empty data, or missing data for some users, check the current time range, data permissions, Organization ID, user role, page filters, data source, API status, and possible cache or synchronization delay.

If only some users are affected, start with role and data-permission checks.

Configuration changes not taking effect

If frontend behavior does not change after updating system configuration, check whether the configuration was saved, whether the correct Organization was modified, whether the current user had permission, whether there is activation delay, whether the App needs to re-enter the page or sign in again, and whether an external system is caching old configuration.

Operation Logs can confirm whether the change was recorded by the system.

IP whitelist issues

If access fails after enabling IP whitelist, check whether the current public IP is correct, whether dynamic IP is being used, whether VPN changed the egress IP, whether the office network has multiple egress points, and whether the actual API server egress IP matches the configuration.

Confirm the actual public IP first, then compare it with the whitelist configuration.

System errors

For internal system exceptions such as pages failing to load, Internal Server Error, temporarily unavailable services, data processing failure, or scheduled task failure, record the problem time, page or feature name, Organization ID, User ID, Request ID, Error Code, and Error Message.

Then review the related system error records or technical logs according to the deployment and support process.

Using logs for investigation

Finger Manager provides multiple logs for different issue types: Login Logs for login issues, Operation Logs for back-office operation issues, API Logs for API issues, Notification Sending Records for notification issues, Order Error Records for order issues, and system error records for system exceptions.

If an issue involves multiple systems, compare multiple logs by time and identifier.

Information to keep before escalation

When submitting an issue to an internal technical team or Finger Manager support team, provide problem time, Organization ID, User ID, Account ID, Order ID, Client Order ID, Request ID, API Endpoint, Error Code, Error Message, source IP, screenshots, and reproduction steps when available.

Do not send passwords, full API Secrets, Access Tokens, private keys, or other sensitive authentication information through ordinary messages.

Example: API order submission failed

If a user submits an order through API and receives HTTP 403, open API Logs, locate the request by Request ID, check the Error Code, confirm IP_NOT_ALLOWED, check the source IP, compare it with the API IP whitelist, add the correct server egress IP, and send the request again.

This path can quickly identify the issue as an access-source configuration problem.

Example: order rejected

If an order returns RISK_REJECTED, query Order Error Records by Order ID, confirm the failure stage is Risk Check, review the Error Message, inspect account risk restrictions, check order quantity and buying power, then adjust the issue and resubmit when appropriate.

When the source is unclear

If the module is unclear, first record problem time, User ID, Organization ID, page or action name, Request ID or Order ID, and screenshots.

Then check Login Logs, Operation Logs, API Logs, Order Error Records, and system error records in sequence. Cross-querying by time and identifiers usually narrows the source step by step.

Notes

The troubleshooting guide helps institutions quickly locate common issues encountered while using Finger Manager.

Real issues may involve Finger Manager, Finger Trader, API, FIX, brokers, LPs, data services, notification services, and third-party systems at the same time.

For complex issues, combine related logs, external-system return information, and the institution's own technical architecture for investigation.