Organization administrators, security administrators, compliance teams, audit teams, and operations leads
Record important back-office actions in Finger Manager for audit, security management, and troubleshooting.
Record important back-office actions in Finger Manager for audit, security management, and troubleshooting.
Notifications configured in Finger Manager can be delivered precisely inside Finger Trader App according to rules, audience, and schedule.
Operation Logs record important actions performed by back-office users in Finger Manager.
They help institutions understand who performed an action, when it happened, which object was affected, what was done, and what the final result was.
Operation logs are an important part of Finger Manager internal audit, security management, and troubleshooting.
Operation Logs are back-office behavior records automatically generated by Finger Manager.
When a user performs an important action, the system can create a corresponding log for later query and audit.
Examples include signing in, creating customers, editing customer profiles, creating products, changing product configuration, listing or delisting products, publishing announcements, sending Push Notifications, changing user groups, creating roles, editing permissions, creating API Credentials, changing system settings, and other important back-office operations.
Each operation log can include operation time, operator, User ID, Organization, role, module, action type, object, Object ID, before value, after value, request source, IP address, result, failure reason, and remarks.
Different operation types can record different fields according to business needs.
Operation logs record the back-office user who performed the action.
For example, the log can show operator Aki Tanaka, role Operations, and organization Japan Entity.
In group environments, Organization helps distinguish operations performed under different institutional entities.
The system records when each operation happens, such as 2026-08-28 15:32:18 JST.
For institutions operating across countries or regions, the display can be combined with system time-zone settings.
Accurate time records help determine when configuration changed, when notifications were published, when permissions changed, when products were listed or delisted, and when customer information changed.
Logs can be categorized by Finger Manager module, such as Market & Product, Customer, Trading, Content & Notification, Organization, Role, Permission, API, System Settings, and Security.
This helps administrators quickly identify which business area a log belongs to.
The system can record the specific action performed.
Common action types include View, Create, Edit, Update, Delete, Publish, Approve, Enable, Disable, Export, Import, Login, Logout, Send, and Cancel.
For example, Action: Publish means the user performed a publishing operation; Action: Edit means the user changed existing data.
In addition to action type, logs should identify the exact object affected.
For example: Module = Announcement, Action = Publish, Object = US Market Holiday Notice, Object ID = ANN-100238.
This makes it possible to find the exact content that was operated on even when the system contains many announcements or products.
For important data changes, operation logs can record before and after values.
For example, product status can change from Inactive to Active, or price precision can change from 2 to 4.
Before / After comparison helps confirm exactly what changed and is especially useful for configuration troubleshooting.
Market and product management logs can record creating markets, creating desks, adding products, editing product profiles, changing product icons, listing products, delisting products, changing product order, changing trading hours, and changing price precision.
For example, Operations Admin updates AAPL Trading Hours from 09:30-16:00 to 09:30-13:00. The log can trace the full product parameter change process.
Customer management logs can record creating customers, editing customer profiles, changing customer status, adding notes, changing user groups, changing customer ownership, performing customer-related back-office operations, and exporting customer data.
For customer profile changes, logs can record the specific field. For example, Field = Email, Before = [email protected], After = [email protected].
Content and notification logs can record creating, editing, and publishing banners; creating and publishing announcements; creating and publishing popups; creating marquees; sending Push Notifications; sending in-app notifications; sending SMS or Email; creating scheduled tasks; and cancelling scheduled tasks.
For example: Action = Push Notification Send, Target = US Market Users, Recipients = 12,502, Result = Success.
This confirms who sent a notification, who received it, and what the result was.
Organization and permission modules are highly sensitive, so related operations are especially suitable for logging.
Examples include creating roles, editing roles, deleting roles, changing feature permissions, changing data permissions, changing API permissions, assigning roles to users, removing roles, creating back-office users, and disabling back-office users.
For example, Super Admin performs Permission Update on Operations, changing Notification Publish from Disabled to Enabled. This clearly traces permission changes.
Organization logs can record creating Organizations, editing organization profiles, changing organization status, changing parent organization, changing administrators, adjusting organization data permissions, and disabling organizations.
For group customers, these logs help confirm when the organization structure changed and who performed the change.
API management logs can record creating API Credentials, changing API permissions, disabling APIs, revoking tokens, changing IP allowlists, changing Rate Limits, and regenerating Secrets.
These operations usually require high system permissions, so logs should be retained completely.
Actual API request records can be managed separately in API Logs or API Access Logs.
The system can also record account security behavior, such as successful sign-in, failed sign-in, sign-out, password changes, MFA setting changes, SSO sign-in, account lock, account unlock, and permission denial.
For example: Login Failed, User = [email protected], IP = 203.0.113.10, Reason = Authentication Failed.
These logs help institutions identify abnormal login behavior.
Each log can record whether the operation succeeded.
Common statuses include Success, Failed, Rejected, and Cancelled.
For Failed status, the system can further record reasons such as Permission Denied, Validation Failed, Network Error, Provider Error, or API Timeout.
When the log volume is large, search can quickly locate records by user name, User ID, Object ID, product name, customer name, notification title, API Credential, or action type.
For example, searching ANN-100238 can find operation records related to that announcement.
Operation logs can be filtered by time range, operator, Organization, Role, Module, Action, Result, and IP Address.
For example, filtering Time = past 7 days, Module = Permission, Action = Edit can quickly find all recent permission changes.
Administrators can view the operation history of a specific back-office user.
For example, Aki Tanaka performed 12 notification creations, 4 announcement publications, 7 banner edits, and 3 user group changes in the past 30 days.
This helps institutions understand the main system activities of a specific employee.
Logs can also be viewed from a specific business object.
For example, from product AAPL, administrators can see who created the product, changed price precision, changed trading hours, listed it, or delisted it.
This forms a complete object change history.
When a user attempts an unauthorized operation, the system can record the attempt.
For example: User = Customer Service A, Attempted Action = Customer Export, Result = Permission Denied.
These logs help identify permission configuration mistakes, user misoperations, or abnormal access attempts.
When a system configuration issue appears, operation logs help confirm recent changes.
For example, if a product suddenly cannot be traded, administrators can check Product Operation Logs and find that at 15:20 an operations user changed product status from Active to Inactive.
This locates the source quickly without asking every operator manually.
Operation logs are important records for internal management and audit.
Auditors can check who changed customer profiles, exported customer data, changed permissions, published important notifications, changed product parameters, or managed API Credentials.
These records help institutions establish clearer internal accountability boundaries.
Operation logs can be retained according to institution or system rules, such as 90 days, 180 days, 1 year, or multiple years.
Retention periods for different log types can be configured according to business, compliance, or internal management requirements.
Critical permission, security, and trading logs usually should use longer retention periods.
Users with the required permission can export operation logs for internal audit, issue investigation, security analysis, compliance checks, and management reports.
Because logs may contain sensitive business information, Log Export should be managed as an independent permission.
To preserve trustworthiness, normal back-office users should not be able to modify operation logs.
Logs should be generated and saved automatically by the system.
Even if the related business data changes later, the original operation record should remain so that history stays continuous and traceable.
Operation logs can also be restricted by data permissions.
For example, Japan Admin can only view operation logs under Japan Entity, Group Admin can view logs across multiple Organizations, and Security Admin can view cross-organization security logs.
This prevents normal administrators from seeing internal operation records outside their responsibility scope.
For high-risk operations, logs can record more detailed information.
Examples include changing permissions, exporting customer data, changing API permissions, changing security settings, sending notifications in bulk, changing trading parameters, and performing other high-risk back-office operations.
In addition to basic fields, the system can record Session ID, IP, Device, Request ID, Reason, and Approval ID for later investigation.
The workflow can be understood as: back-office user performs an operation -> Finger Manager verifies permissions -> the system executes the business operation -> Operation Log is generated automatically -> user, time, module, object, and result are recorded -> the log is saved -> administrators can search and filter logs -> logs are used for audit or troubleshooting when needed.
Operation Logs are a core Finger Manager capability for back-office audit and issue tracing.
By automatically recording important back-office actions, the system helps institutions continuously trace changes to products, customers, notifications, organizations, permissions, APIs, and system settings.
Operation logs help answer who performed an action, when it happened, what was operated on, what changed, and whether the final result succeeded, improving traceability, security, and troubleshooting efficiency.
