All
Filter by:
How do I deposit cash into my account?
I need help with account verification
Why can't I access my account?
Are there any crypto withdrawal fees?
I need help signing into my account
Security Events
Security events are your Organization’s activity record: every sign-in, permission change, fund movement, and configuration change, with who did it, from where, and when. For institutional teams, this is the surface that answers compliance questions, supports internal audits, and catches anomalies early.
Security events cover activity across the whole Organization:
Category | Example events |
|---|---|
Sign-in and session | Signed in, signed out, failed sign-in attempts, 2FA challenges and changes |
Devices | Device linked, device trusted, device approved, device revoked |
Fund movement | Withdrawal requested, funds deposited, transfer initiated and completed |
Addresses | Withdrawal address added, updated, removed |
Team | Roles created, updated, deleted; roles assigned to and removed from Members |
API keys | API key created, updated, deleted |
Accounts | Account created, added to or removed from the Organization |
Approvals | Approval request created, approval decision submitted, across every workflow |
Policies | Policy updated, policy locked, policy unlocked |
Failed sign-in attempts are recorded alongside successful ones. A string of failed sign-ins from an unfamiliar location is precisely the signal this surface exists to show you.
Each event answers the questions an auditor, or an incident responder, asks first:
Column | What it tells you |
|---|---|
Action | What happened, in plain language: signed in, withdrawal requested, API key created |
Actor | Who did it, the Member, or the API key that initiated the action |
OS | The operating system of the device behind the action |
Browser | The browser or client the action came from |
Location & IP | The geographic origin and IP address of the request |
Request ID | For governed operations, the approval request that authorized the action |
Date | When it occurred |
Events produced by a user’s session carry the full client context, OS, Browser, Location & IP. Events executed by the system on the user’s behalf carry the Request ID instead: the client context lives on the approval events for that request.
When a governed operation runs, its security events carry the ID of the approval request behind it. From the Request ID you can open the request and see who initiated it, who approved, who rejected, and when each decision was made.
This closes the audit loop. For any fund movement or administrative change, you can reconstruct the full chain: the action, the request behind it, and the humans who signed off, without leaving the product.
Direct operations, sign-ins, device changes, credential changes, are recorded as events without a Request ID, since they complete without approval by design.
- Go to Security in your Organization.
- Filter by Member, Event type, or Date range.
- For events tied to a governed operation, follow the Request ID to the approval request and its review trail.
- Use Export to download the filtered result set for offline review or archiving.
Who can see security events follows the same access model as everything else: visibility is part of the relevant workflow levels in a Member’s Workflow Profile.
Periodic access review. Filter for role and policy changes over the review period. Each change links to its approval request through the Request ID, giving you the change and its authorization in one view.
Incident triage. Failed sign-ins and unfamiliar locations stand out in the Location & IP column. Filter by Member to reconstruct a session’s full activity.
Reconciliation. Fund-movement events carry their Request ID, so your finance team can match ledger entries to the requests and approvals that produced them.
Troubleshooting
The Actor, OS, Browser, and Location & IP columns identify who performed the action and from where. If the actor is a Member, confirm with them directly. If the activity is genuinely unrecognized, an unfamiliar location or device, treat it as a potential compromise: deactivate the Member or revoke the API key involved, and contact support.
Only governed operations carry a Request ID. Direct operations, sign-ins, device changes, credential changes, complete without an approval request by design, so the column is empty for them.
Events executed by the system on a user’s behalf, for example, the changes applied after a request is approved, have no client session of their own. Follow the Request ID to the approval request: the events for starting and reviewing the request carry the client context of the people involved.