Account & Wallet Usage with Applied Exemptions
Account Usage
1. Restriction Handling for Outdated KYC
When an account is identified as having outdated KYC information (KYC_OUTDATED), Lemonway applies restrictions to ensure ongoing compliance with regulatory requirements.
This situation typically occurs when:
- The verification due date has been reached or passed
1.2 Where this information is available
You can identify this situation through the following channels:
1. Lemonway Dashboard
The account status and restriction details are visible directly in your organisation’s Lemonway Dashboard.
2. GET /accounts
The account will include a requirement indicating a pending KYC update:
{
"requirements": [
{
"id": "6ca90af5-4892-4cfb-b5fe-56b95a85e987",
"type": "KYC_UPDATE",
"dueDate": "2026-04-11T18:01:33.908Z",
"status": "REQUESTED"
}
],
"restrictions": []
}GET /accounts/{id}
Once restrictions are applied, the response will also include a restriction object:
{
"requirements": [
{
"id": "6ca90af5-4892-4cfb-b5fe-56b95a85e987",
"type": "KYC_UPDATE",
"dueDate": "2026-04-11T18:01:33.908Z",
"status": "REQUESTED"
}
],
"restrictions": [
{
"id": "5690c336-ac61-451c-ae2d-0c02d3748557",
"category": "KYC",
"reason": "KYC_OUTDATED",
"activatedAt": "2026-03-12T19:02:06.269Z",
"requirementIds": [
"6ca90af5-4892-4cfb-b5fe-56b95a85e987"
]
}
]
}2.Wallet Usage
2. 1 Restriction Behaviour
FULL Block ·
isBlocked = trueDefault behaviour when no exception applies
When applied
- Account has
restriction.reason = KYC_OUTDATED - No exception criteria match
| Transaction Family | Status |
|---|---|
| Pay In | Blocked |
| Pay Out | Blocked |
| P2P In | Blocked |
| P2P Out | Blocked |
Default compliance restriction state
PARTIAL Block / Restriction ·
isRestricted = trueApplied when an exception scenario is triggered
When applied
- Account has
restriction.reason = KYC_OUTDATED - One of the defined exception cases applies
| Transaction Family | Description | Configurable Parameters |
|---|---|---|
| Pay In | Fund deposits to wallet | Amount per operation, 24h count, 24h amount |
| Pay Out | Fund withdrawals from wallet | 24h count, 24h amount, monthly amount |
| P2P In | Peer-to-peer received transfers | 24h count, 24h amount |
| P2P Out | Peer-to-peer sent transfers | 24h count, 24h amount |
Restriction logic depends on the applicable exception case
2.2 Exception Scenarios
Scenario 1: Crowdfunding Investors & Lenders
Objective
Enable users to receive reimbursements and dividend distributions, while preventing any outbound transactions.
Transaction Rules
Users are restricted to
inbound P2P transfers only.
Transaction Permissions
| Transaction | Status |
|---|---|
| Pay In | Blocked |
| Pay Out | Blocked |
| P2P Out | Blocked |
| P2P In | Allowed |
Inbound-only recovery flow
Scenario 2: Crowdfunding Project Holders
Objective
Enable project holders to receive investments and fulfil reimbursement obligations, while preventing withdrawals.
Transaction Rules
Pay In and P2P Out are allowed.
Transaction Permissions
| Transaction | Status |
|---|---|
| Pay In | Allowed |
| Pay Out | Blocked |
| P2P In | Blocked |
| P2P Out | Allowed |
Controlled funding and reimbursement flows
Updated about 4 hours ago
