Error page segmentation & infinite retry loop prevention
Feature Improvement When key engine processes — such as ID liveness, selfie (Passive) liveness, face comparison, or Korean government authenticity verification — fail consecutively, users were previously caught in an infinite retry loop. With this improvement, if the same error accumulates 3 times, the user is now directed to a dedicated error page for that specific error type instead of being offered another retry. Fewer than 3 occurrences are still handled with a recapture prompt or notification.New error codes
Engine errors (SE) — each engine has its own dedicated error page, so you can immediately identify which engine failed.
LO) — when the same error accumulates 3 times during ID capture or step processing, the user is moved to a loop-block page. Unmapped loop errors fall back to a generic page.
Error Handling Method — Warning conversion & Custom Policy integration
You can configure how each engine error is handled in the dashboard:Error (default — redirect to a dedicated error page) ↔ Warning (skip that verification and continue). This is set per item for ID Liveness · Selfie Passive Liveness · Korean government verification.
When set to Warning, the user is not redirected to an error page; only that verification is skipped and the subsequent KYC process continues. The resulting Warning record can then be caught by the “Warning occurred” trigger in Custom Policy, applying follow-up actions such as ARGOS Score penalties, holding (Pending), or rejection per your policy. (This follows the same pattern as the Expired ID Warning handling.)
Unsupported browser and device notification improvements
Feature Improvement When users access the liveform from unsupported environments — including older browsers, environments without WebAssembly support, or devices running Android OS below version 9 — they previously received only a generic notice with no error code. This improvement assigns the error codeRT-60002 and includes a link to the supported environment guide. Clients can now immediately identify the reason for the block and provide users with specific guidance.
Administrator permission management (RBAC) improvements
New Feature Permissions (roles) for ARGOS internal administrators and project external administrators are now separated, with each role independently controlling which items can be viewed, modified, or deleted on the dashboard. Roles are divided into Owner, Leader, Member, and Guest.
Administrator Settings — role-based (Owner·Leader·Member·Guest) permission separation and administrator list
Personal information display control
Depending on the assigned role, data fields in a user’s submission are displayed masked. In the Personal Info Visibility by Role setting, you specify per item which roles (Owner·Leader·Member·Guest) can see each piece of personal information (PII) — such as resident registration numbers, document numbers, identification numbers, and ID card images — and any unchecked item appears masked to administrators with that role.John Doe → ***, Date of Birth 1990-01-15 → ****-**-**)
Personal Info Visibility by Role — per-role display/masking of submission data fields
Permission-based feature control
Actions that exceed a role’s permission scope — such as saving options, deleting records, or canceling administrator invitations — are handled consistently: the relevant button is either hidden entirely or accompanied by a permission notice. This prevents unauthorized operations at the source.ARGOS continues to improve its identity verification service for stronger security and a better user experience. Thank you for using ARGOS Identity. The ARGOS Identity team