Eligibility Engine은 이용 조건과 한도를 어떻게 결정하는가?

Eligibility Engine은 근로자가 신청할 때 EWA 이용 조건을 확인하는 계층입니다. 임금을 만들어 내는 것이 아니라 계산된 기발생 임금 결과를 받아 프로필 상태, 기업 정책, 이용 한도와 통제 조건을 적용한 뒤 신청 진행 여부와 허용 범위를 결정합니다.

Eligibility Engine은 어떤 질문에 답하는가?

EWA에서는 다음 두 질문을 혼동하기 쉽습니다.

1. 승인된 근무로 근로자가 이미 얻은 임금은 얼마인가?
2. 현재 이 사람이 서비스를 이용할 자격이 있으며 어느 범위까지 받을 수 있는가?

첫 번째 질문은 Earned Wage Engine, 두 번째 질문은 Eligibility Engine의 영역입니다.

두 계층을 분리하면 노동으로 이미 만들어진 가치와 금융 기능을 사용할 수 있는 권한을 혼동하지 않습니다.

근로자에게 승인된 근무일이 있어도 프로필 조건이 아직 완료되지 않았을 수 있습니다. 반대로 프로필은 완전하지만 받을 수 있는 기발생 임금이 아직 부족할 수도 있습니다.

일반적으로 확인하는 여섯 가지 조건 그룹

좋은 Eligibility Engine은 조건을 업무상 의미가 분명한 그룹으로 구성해야 합니다.

확인 그룹	답해야 할 질문	데이터 출처
근로자 상태	프로필이 활성 상태이며 적용 범위에 속하는가?	HRM/ERP
근무 및 기발생 임금	이미 형성된 기발생 임금이 있는가?	Earned Wage Engine
기업 정책	해당 근무지에서 정책을 활성화했는가?	Policy/configuration
신원 및 계좌	수령 프로필이 확인되었는가?	Identity/account
이용 한도	현재 신청이 허용 범위 안에 있는가?	Policy + transaction ledger
시스템 상태	중단 또는 보류가 필요한 조건이 있는가?	Transaction/monitoring

각 조건에는 명확한 데이터 출처와 담당자가 있어야 합니다.

기준 정보가 없는 데이터에 규칙이 의존하면 근로자가 거절되거나 제한된 이유를 설명하기 어렵습니다.

한도는 정책의 결과이지 임금 자체가 아니다

EWA에서 “한도”는 근로자에게 미리 부여된 별도의 금액으로 이해해서는 안 됩니다.

먼저 Earned Wage Engine이 이미 형성된 임금을 계산합니다.

그다음 Eligibility Engine은 규칙을 적용해 허용되는 이용 범위를 좁힐 수 있지만, 자격 있는 기발생 임금보다 큰 가치를 만들어서는 안 됩니다.

다음과 같이 표현할 수 있습니다.

이용 가능 가치 ≤ 이미 형성된 자격 있는 기발생 임금

Nhan Kiet의 기발생 임금 접근 서비스에서 기본 계산식은 다음과 같습니다.

수령 가능 금액 = (승인된 근무일수 × 일급) − 해당 기간 기수령액 − 기업 규정에 따른 유보액.

그 후 다른 이용 조건을 평가합니다.

신청 시점에 다시 확인해야 하는 이유는 무엇인가?

앱에 표시된 “이용 가능” 상태가 이미 오래된 정보일 수 있습니다.

근로자가 화면을 열고 확인 버튼을 누르는 사이에 다음 상황이 발생할 수 있습니다.

• 근무 기록 수정
• 다른 거래 성공
• 근로자 상태 변경
• 계좌가 더 이상 유효하지 않음
• 정책이 새 버전으로 변경됨
• 이전 거래가 여전히 대기 중임

따라서 서버는 신청을 생성하는 시점에 조건을 다시 평가해야 합니다.

화면은 정보만 표시해야 하며 최종 결정은 서버의 최신 데이터를 기준으로 해야 합니다.

Eligibility Engine과 Earned Wage Engine은 어떻게 다른가?

계층	핵심 질문	주요 데이터
Earned Wage Engine	형성된 기발생 임금은 얼마인가?	근무, 단가, 기수령액, 유보액
Eligibility Engine	현재 이 사람이 이용할 수 있으며 허용 범위는 얼마인가?	프로필, 정책, 한도, 계좌
Payment Orchestration	유효한 신청을 거래로 어떻게 처리하는가?	거래 ID, 상태, 은행

세 계층을 분리하면 각 계층의 책임이 명확해집니다.

근무가 바뀌면 Earned Wage Engine이 재계산합니다. 정책이 바뀌면 Eligibility Engine이 재평가합니다. 은행 네트워크에서 시간 초과가 발생하면 Payment Orchestration이 거래 상태를 처리합니다.

정책에는 버전과 효력 발생일이 필요하다

흔한 설계 오류는 “현재 정책”만 저장하는 것입니다.

몇 달 후에는 예전 거래는 허용되었는데 다른 시점의 유사 거래는 허용되지 않은 이유를 기업이 설명하기 어려울 수 있습니다.

각 규칙 세트에는 다음 항목이 필요합니다.

• 버전 코드
• 효력 발생 일시
• 적용 범위
• 작성자
• 승인자
• 변경 사유
• 활성/비활성 상태

신청을 평가할 때 시스템은 사용된 정책 버전의 이력을 저장해야 합니다.

Eligibility Engine은 언제 중단해야 하는가?

중요한 데이터가 충분히 확실하지 않다면 엔진은 자동으로 권한을 열어서는 안 됩니다.

예시는 다음과 같습니다.

• 이전 거래 상태가 불명확함
• 원천 근무 기록이 서로 충돌함
• 수령 계좌가 유효하지 않음
• 프로필이 더 이상 활성 상태가 아님
• 적용 정책 버전을 결정할 수 없음
• 원천 시스템이 확인 가능한 방식으로 응답하지 않음

이러한 경우 안전한 설계는 모든 것이 정상이라고 가정하는 대신 신청을 확인 대기 상태로 유지하는 것입니다.

이는 자금 처리 시스템에서 사용하는 것과 같은 실패 시 차단 원칙입니다.

사유 코드는 결과만큼 중요하다

Eligibility Engine은 다음만 반환해서는 안 됩니다.

• true
• false
• 숫자 하나

다음과 같은 구조화된 사유를 반환해야 합니다.

• 승인된 근무일 없음
• 프로필 미확인
• 고객사가 기능을 활성화하지 않음
• 신청이 허용 범위를 초과함
• 대기 중 거래가 있음
• 계좌 재확인이 필요함

사유 코드는 다음에 도움이 됩니다.

• 화면에서 사용자에게 결과 설명
• 지원팀의 조회
• 운영팀의 오류 분류
• 통계 측정
• 의사결정 감사

민감한 기술 세부사항을 공개할 필요는 없지만 사용자는 다음 조치를 알아야 합니다.

기업은 Eligibility Engine을 어떻게 관리해야 하는가?

Eligibility Engine은 단순한 코드가 아니라 실행 가능한 정책으로 관리해야 합니다.

각 중요 규칙에는 다음이 필요합니다.

• 업무 담당자
• 데이터 출처
• 효력 발생일
• 존재 이유
• 적용 범위
• 예외 처리 방식
• 변경 이력

제품팀과 급여팀은 형성된 임금과 이용 허용 부분의 경계를 합의해야 합니다.

운영팀은 신청이 보류된 이유를 알아야 합니다.

지원팀은 민감한 기술 설정에 접근하지 않고도 설명할 수 있을 만큼 명확한 사유 코드를 사용해야 합니다.

모니터링할 KPI

다음 지표를 추적할 수 있습니다.

• 자격 충족 비율
• 승인된 근무 부족으로 인한 보류 비율
• 프로필 또는 계좌로 인한 보류 비율
• 대기 거래 때문에 차단된 신청 수
• 정책 변경 건수
• 자격 조건 관련 이의 제기 수
• 완전한 사유 코드가 있는 결정의 비율
• 수동 처리가 필요한 예외 건수

KPI를 “가능한 많은 사람의 거래를 허용”하는 방향으로 최적화해서는 안 됩니다. 목표는 조건에 맞고, 설명 가능하며, 일관된 결정입니다.

결론

Eligibility Engine은 EWA가 이미 형성된 기발생 임금과 특정 시점의 서비스 이용 권한을 명확히 분리하도록 돕습니다. 좋은 엔진은 신청 시점에 조건을 재평가하고, 버전이 있는 정책을 사용하며, 명확한 사유 코드를 반환하고, 중요한 데이터가 불확실할 때 중단합니다. 이를 통해 기업은 정책을 변경하면서도 급여 무결성과 근로자에게 설명할 수 있는 능력을 유지할 수 있습니다.

작성자: Do Huy Le — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.

기업용 기발생 임금 접근 상담: Hotline 0937.022.655 · Email info@nhankiet.vn · 기업용 기발생 임금 접근 서비스