Transaction type is a category of the activity represented by a certain record.

Transaction types determine how to process and evaluate the event. Depending on the type, transactions contain different sets of required and optional fields.

Sumsub supports the following types:

Finance — Fiat and crypto movements such as deposits, withdrawals, transfers, payments, or refunds.
Verification Session — A system-generated event (not submitted via API) that is automatically created (if enabled for the selected level) when an applicant completes a KYC/KYB onboarding flow at a specific level or finishes verification checks. This event can be evaluated based on your risk matrix and applicable rules. The resulting score is assigned to the applicant.
Travel Rule — Transactions related to the Travel Rule data exchange for crypto transfers between VASPs or between a VASP and an unhosted wallet. These include originator/beneficiary information, asset details, and blockchain identifiers required to comply with Travel Rule regulations and to monitor risk on these transfers.
User Platform Event — Non-financial user actions inside your product/service that are relevant for monitoring (for instance, failed and successful logins, 2FA or password reset, or any other significant user action you would like to monitor and act on). You can use such events to trigger additional checks, such as liveness or email and phone verification and protect accounts from takeover.
Scheduled event — A free system-generated event not submitted via API that indicates that a rule condition has been met during a periodic verification of the applicant.
iGaming Session — A system-generated transaction type (not submitted via API). It is automatically created based on submitted bets, and is used within the iGaming solution to detect suspicious gaming patterns and support Responsible Gaming (RG) monitoring and compliance workflows.

📘
Note
The same crypto withdrawal can have both a Finance and a Travel Rule transaction, so you can monitor financial patterns and Travel Rule compliance together.

Use cases

In the table below, you can find examples of transaction use cases with its key fields that define a specific transaction type.

Transaction type	Use case	Key fields
Finance	Fiat card deposit into account A customer tops up their balance by 500 EUR using a debit card. The operation must be screened for AML risk (high-risk geography, card country mismatch, etc.). It allows you to detect unusual funding behaviour (for example, sudden spikes in deposits or repeated attempts just below configured limits).	`type = "finance"` — classifies the record as a financial transaction. `info.direction = "in"`, `info.amount = 500`, `info.currencyCode = "EUR"`, `info.currencyType = "fiat"` — describe that this is an incoming fiat deposit and its amount/currency. `applicant.paymentMethod.type = "card"`, `applicant.paymentMethod.accountId` — identify the card used and make it available for card-level risk checks and limits.
	Crypto withdrawal to external wallet A user withdraws 0.005 BTC from their platform balance to an external wallet. The transaction should be checked for unusual amount patterns, previous risk flags, and high-risk wallet characteristics. Monitoring such withdrawals enables you to identify potentially sanctioned or risky destinations, and detect rapid outflows after large inflows.	`type = "finance"` — classifies the record as a financial transaction. `info.direction = "out"`, `info.amount = 0.005`, `info.currencyCode = "BTC"`, `info.currencyType = "crypto"` — indicate an outgoing crypto withdrawal and the asset/amount. `applicant.paymentMethod.type = "crypto"`, `applicant.paymentMethod.accountId` — store the originating wallet/address on your side (e.g. internal wallet ID), while `counterparty.paymentMethod.accountId` can be used for the external destination wallet.
	Internal P2P transfer between users One user sends 200 USD from their wallet to another user on the same platform (P2P transfer). These operations must be monitored to detect structuring, mule accounts and circular transactions.	`type = "finance"` — classifies the record as a financial transaction `info.direction = "out"` — indicates the sender's perspective, `info.amount = 200`, `info.currencyCode = "USD"` — indicates amount and currency. `applicant.externalUserId` (sender) and `counterparty.externalUserId` (receiver) — user identifiers on the client side.
User Platform Event	Suspicious login pattern A user has several failed login attempts from a new device and IP, followed by a successful login. These sequences may indicate credential stuffing or account takeover. Recording each event allows you to correlate unusual authentication behavior with subsequent financial or KYC actions, so you can react before any monetary loss occurs.	`type = "userPlatformEvent"` — denotes a behavioral/platform event, not a financial transaction. `userPlatformEventInfo.type = "login"` (`"failedLogin"` as subtype for failed attempts) — differentiates between event kinds in rules. `applicant.device.ipInfo.ip`, `applicant.device.fingerprint` — capture IP, device fingerprint for anomaly detection.
User Platform Event	Password reset/2FA reset request A user initiates a password reset or 2FA reset from an unfamiliar device and IP. Such events are critical for detecting attempted account takeover and should be monitored closely. When seen together with failed logins, new devices or high-risk geolocation, these resets can provide a strong signal that the account is compromised and further authentication is required.	`type = "userPlatformEvent"` — classifies the record as a platform event. `userPlatformEventInfo.type = "passwordReset"` or `"twoFaReset"` — distinguishes security-sensitive actions from general logins. `applicant.device.ipInfo.ip`, `applicant.device.fingerprint`, `applicant.device.userAgent` — capture detailed device and browser info for risk assessment.
Verification Session	New user onboarding An account appears on the platform. This event is used to detect session spikes from risky IP ranges, devices reused across multiple accounts, and abuse of bonuses or referrals. Tracking sessions gives you a complete timeline of the user lifecycle, and helps create stronger risk models that combine origin, device reputation and subsequent behavior.	`type = "kyc"` — classifies the record as a platform event. `applicant.country` — specifies the country of the applicant. `applicant.riskLabels.device` — contains risk-related tags associated with the applicant's devices. `applicant.phone.country` — identifies the country associated with the applicant's phone number. `applicant.assessment.totalScore` — identifies a total score calculated during Applicant risk scoring.
Travel Rule	Withdrawal to an external VASP A customer initiates a crypto withdrawal above the Travel Rule threshold to an external VASP. Before broadcasting the blockchain transaction, your platform initiates a Travel Rule data exchange to send originator information and receive beneficiary details.	`type = "travelRule"` — indicates that the transaction belongs to the Travel Rule data exchange flow rather than a standard financial transfer. `info.amount`, `info.currencyCode`, `info.cryptoParams.cryptoChain`, `info.paymentTxnId` — describe the on-chain asset and amount, link the Travel Rule event to the blockchain transaction hash, and specify the crypto chain.
Scheduled Event	Periodic applicant review The system triggers a periodic check of applicants starting from the date of their last review. The logic is based on the applicant’s risk profile criteria to ensure that user data and risk levels remain current. This allows for the timely detection of profile changes or patterns that require attention over time.	`type = "scheduledEvent"` — identifies the record as an automated system event. `applicant.reviewDate` — identifies the date of the last check to calculate the timing for the next review. `applicant.tags` — filters applicants by assigned categories to apply specific review logic. `applicant.reviewStatus` — indicates the current status of the review process.
iGaming Session	Aggregated session activity monitoring The system aggregates bets into a single session record. Monitoring players behaviour lets you analyze betting intensity, duration, and financial outcomes and detect high-risk patterns or significant fluctuations without processing each bet as a separate transaction.	`type = "iGgamingSession"` — identifies the record as an aggregated gaming session. `gameName`, `betType`, `durationMs` — specify the game title, category, and the total time spent. `wageredTotalInDefaultCurrency`, `winLossInDefaultCurrencyCount` — capture the total volume, net outcome, and number of bets.