결제 처리 데이터 템플릿
결제 처리 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- ACI Worldwide 데이터 추출 안내
결제 처리 속성
| 이름 | 설명 | ||
|---|---|---|---|
| 결제 거래 ID PaymentTransactionId | ACI 시스템에서 개별 결제 지시를 식별하는 고유 ID입니다. | ||
| 설명 이 속성은 process mining 분석의 기준 키로, 하나의 결제 요청과 관련된 모든 이벤트를 연결합니다. ACI Worldwide 시스템(예: MTS 또는 UPP)에서는 거래 입력 시 부여되는 고유 참조 번호에 해당합니다. 이를 통해 최초 요청부터 검증, 승인, 최종 정산까지 결제의 전체 흐름을 재구성할 수 있습니다. 중요한 이유 개별 이벤트를 프로세스 인스턴스별로 묶는 데 필요한 기본 Case ID입니다. 확보 방법 거래 기본 테이블에서 TRN_REF, REFERENCE_NUM 또는 UUID와 같은 이름의 열을 확인합니다. 예시 TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| 이벤트 타임스탬프 EventTimestamp | 활동이 발생한 날짜와 시간입니다. | ||
| 설명 이 속성은 ACI 환경에서 이벤트가 발생한 정확한 시각을 기록합니다. 처리 시간, 승인 소요 시간, 처리량 등 시간 기반 지표를 계산하는 데 사용합니다. 자동화된 단계의 순서를 정확히 파악하려면 밀리초 단위의 정밀도가 바람직합니다. 중요한 이유 이벤트 순서를 정하고 처리 시간을 계산하는 데 필요합니다. 확보 방법 거래 이력 또는 감사 테이블에서 'Created Date'나 'Update Date' 열을 확인합니다. 예시 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| 활동 이름 ActivityName | 결제 수명 주기에서 발생한 구체적인 단계 또는 상태 변경입니다. | ||
| 설명 이 속성은 '결제 요청 생성' 또는 '자금 이체'와 같은 이벤트 노드를 프로세스 맵에 표시합니다. ACI 시스템에서는 상태 코드, 감사 로그의 작업 유형 또는 워크플로 상태 변경을 바탕으로 도출하는 경우가 많습니다. 이러한 기술 상태를 이해하기 쉬운 업무 활동으로 정확히 매핑해야 의미 있는 시각화를 만들 수 있습니다. 중요한 이유 프로세스 흐름을 정의하며, 작업 순서를 시각화하는 데 필요합니다. 확보 방법 상태 코드(예: 100=생성, 200=검증 완료) 또는 감사 로그의 작업 열에서 도출합니다. 예시 결제 요청 생성결제 승인 완료결제 정산 완료결제 실패 | |||
| 결제 금액 PaymentAmount | 결제 거래의 금액입니다. | ||
| 설명 이체되는 금액을 나타냅니다. '결제 처리량'을 분석하고 병목의 우선순위를 정할 때 필요한 정보입니다. 고액 결제는 소액 자동 처리보다 승인 절차가 더 엄격한 경우가 많으므로, 변형 분석에도 활용할 수 있습니다. 중요한 이유 금액별로 데이터를 구분하고 총 처리 금액을 계산할 수 있습니다. 확보 방법 거래 상세 테이블에서 AMT, TRANS_AMOUNT 또는 PRINCIPAL_AMOUNT와 같은 필드를 확인합니다. 예시 1500.00250000.5050.001000000.00 | |||
| 결제 기한 PaymentDueDate | 정시 결제로 처리되기 위해 결제를 완료해야 하는 날짜입니다. | ||
| 설명 계약상 또는 요청된 실행 날짜를 저장합니다. 실제 정산 날짜와 비교해 '정시 결제율' KPI를 계산하고 '결제 기한 규정 준수' 대시보드를 지원합니다. 중요한 이유 SLA 준수 여부와 정시 처리 성과를 측정하는 기준입니다. 확보 방법 결제 지시에서 VALUE_DATE, EXECUTION_DATE 또는 DUE_DATE와 같은 필드를 확인합니다. 예시 2023-11-012023-11-05 | |||
| 결제 유형 PaymentType | 결제 수단의 분류입니다. | ||
| 설명 결제를 전신 송금, ACH, SEPA, RTGS 등으로 분류합니다. 결제 유형에 따라 SLA와 프로세스 흐름이 크게 다를 수 있습니다. '종단 간 결제 처리 시간' 대시보드에서 주요 필터로 사용합니다. 중요한 이유 고속 결제와 일괄 처리 결제를 구분하는 데 필요합니다. 확보 방법 거래 기본 정보에서 PMT_TYPE, INSTRUMENT_TYPE 또는 SERVICE_ID와 같은 필드를 확인합니다. 예시 국내 전신 송금해외 전신 송금ACH 입금즉시 결제 | |||
| 결제 통화 PaymentCurrency | 결제 금액의 ISO 통화 코드입니다. | ||
| 설명
중요한 이유 결제 금액을 올바르게 해석하는 데 필요합니다. 확보 방법 거래 상세 테이블에서 CCY, CURRENCY_CODE 또는 ISO_CODE와 같은 필드를 확인합니다. 예시 USDEURGBPJPY | |||
| 부서 Department | 현재 활동을 담당하는 내부 부서입니다. | ||
| 설명
중요한 이유 업무 기능별 성과를 집계합니다. 확보 방법 사용자 테이블 또는 조직 계층 매핑에서 도출합니다. 예시 운영Compliance자금 관리IT 지원 | |||
| 오류 코드 ErrorCode | 결제가 실패하거나 수정이 필요할 때 생성되는 코드입니다. | ||
| 설명 '결제 실패' 또는 '결제 오류 확인' 이벤트의 구체적인 원인을 기록합니다. '결제 실패 및 재작업 분석' 대시보드에서 이 속성별로 데이터를 묶으면 '잔액 부족', '계좌 정보 오류' 등 자주 발생하는 실패 원인을 파악할 수 있습니다. 중요한 이유 프로세스 실패의 근본 원인을 분석하는 데 필요합니다. 확보 방법 오류 로그 또는 상태 사유 열에서 REASON_CODE나 RETURN_CODE와 같은 필드를 확인합니다. 예시 R01AM04BE05TECH_ERR_001 | |||
| 이벤트 사용자 EventUser | 활동을 수행한 사용자 ID 또는 시스템 에이전트입니다. | ||
| 설명 승인을 수행한 사용자나 자동 정산을 처리한 시스템 계정 등 작업 주체를 기록합니다. 특정 사용자나 대기열에 업무가 몰리는지 파악하는 병목 분석에 중요합니다. 중요한 이유 리소스 분석과 직무 분리 감사에 활용할 수 있습니다. 확보 방법 감사 로그 또는 거래 테이블의 'UpdatedBy' 열에서 확인합니다. 예시 SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS | |||
| 재작업 여부 IsRework | 결제 과정에서 활동이 반복되었는지 나타내는 표시입니다. | ||
| 설명 데이터 처리 중 계산하는 불리언 값입니다. '결제 세부 정보 검증'과 같은 활동이 두 번 이상 발생하거나 오류 루프가 감지되면 true로 설정합니다. 이 값은 '결제 재작업률' KPI 계산에 사용됩니다. 중요한 이유 복잡한 프로세스 쿼리 없이 비효율적인 사례를 빠르게 찾을 수 있습니다. 확보 방법 데이터 파이프라인에서 사례별 중복 활동을 확인해 계산합니다. 예시 truefalse | |||
| 처리 채널 ProcessingChannel | 결제 요청이 시작된 채널입니다. | ||
| 설명 모바일, 웹 포털, API 또는 파일 업로드 등 결제가 접수된 경로를 나타냅니다. 결제 프로세스 변형 분석을 통해 특정 채널에서 오류나 지연이 더 자주 발생하는지 확인할 수 있습니다. 중요한 이유 입력 방식별로 성과를 비교할 수 있습니다. 확보 방법 거래 기본 정보에서 CHANNEL, SOURCE_TYPE 또는 INPUT_METHOD와 같은 열을 확인합니다. 예시 SWIFT인터넷 뱅킹모바일 앱파일 업로드 | |||
| 결제 지연 여부 IsPaymentLate | 결제가 기한 이후에 정산되었는지 나타내는 표시입니다. | ||
| 설명 실제 정산 날짜와 중요한 이유 규정 준수 보고를 간소화합니다. 확보 방법 계산식: SettlementDate > PaymentDueDate. 예시 truefalse | |||
| 대사 ID ReconciliationId | 결제를 총계정원장 또는 대사 기록과 연결하는 ID입니다. | ||
| 설명 '결제 대사 완료' 활동이 발생하면 이 ID가 입력됩니다. 이를 통해 처리 엔진의 결제와 회계 시스템의 항목이 일치하는지 확인합니다. 정산된 결제에 이 ID가 없으면 대사 실패를 의미할 수 있습니다. 중요한 이유 '결제 대사 효율' 대시보드에 필요합니다. 확보 방법 대사 테이블 또는 RECON_REF, GL_REF와 같은 필드를 확인합니다. 예시 REC-9921GL-Entry-2023-11 | |||
| 소스 시스템 SourceSystem | 이벤트 데이터가 생성된 시스템의 이름입니다. | ||
| 설명 ACI Worldwide 생태계 내의 특정 애플리케이션이나 모듈(예: ACI MTS, ACI UPF) 또는 흐름에 관여하는 외부 시스템을 식별합니다. 여러 원장에 걸쳐 데이터를 연결하거나 결제가 외부 청산 기관을 거치는 경우 특히 중요합니다. 중요한 이유 데이터를 추출한 위치를 파악할 수 있어 데이터 계보를 추적하고 문제를 해결하는 데 유용합니다. 확보 방법 데이터 추출 시 값을 고정하거나, 여러 인스턴스가 있는 경우 SystemID 열에서 가져옵니다. 예시 ACI MTSACI UPPSAP GLSwift Gateway | |||
| 수취인 이름 BeneficiaryName | 결제 대금을 받는 주체의 이름입니다. | ||
| 설명 거래 상대방을 식별합니다. 이 필드를 분석하면 재작업률이 높거나 지연이 잦은 특정 공급업체 또는 고객을 파악해 '결제 실패 및 재작업 분석'에 활용할 수 있습니다. 중요한 이유 결제 대상을 식별하며, 고객 중심 분석에 유용합니다. 확보 방법 결제 상세 항목에서 CREDITOR_NAME, BENE_NAME 또는 PAYEE와 같은 필드를 확인합니다. 예시 Acme CorpGlobal Supplies LtdJohn Smith | |||
| 승인 소요 시간 ApprovalCycleTime | 승인 단계에 걸린 시간입니다. | ||
| 설명 '결제 승인 요청'부터 '결제 승인' 또는 거부까지 걸린 시간을 계산합니다. 이 지표는 '결제 승인 소요 시간 분석' 대시보드에 반영되어 사람의 판단이 필요한 단계에서 발생하는 지연을 보여줍니다. 중요한 이유 프로세스 중 사람의 판단에 의존하는 구간을 분리해 측정합니다. 확보 방법 계산식: Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval). 예시 4시간15분 | |||
| 요청 발생 지역 OriginatingRegion | 결제 요청이 시작된 지리적 지역입니다. | ||
| 설명 요청자의 실제 또는 논리적 위치를 나타냅니다. 결제 프로세스 변형 분석을 통해 특정 지역에서 표준과 다른 경로를 따르거나 거부율이 높은지 확인할 수 있습니다. 중요한 이유 프로세스 성과를 지리적 맥락에서 파악할 수 있습니다. 확보 방법 거래 기본 정보에서 지점 코드 또는 국가 코드를 바탕으로 확인합니다. 예시 북미유럽·중동·아프리카아시아·태평양 | |||
| 최종 데이터 업데이트 LastDataUpdate | 레코드를 마지막으로 추출하거나 데이터 모델을 업데이트한 시각입니다. | ||
| 설명 분석에 사용된 데이터의 최신 여부를 추적합니다. 프로세스 이벤트가 발생한 시각이 아니라 데이터를 수집한 기술적 시각입니다. 분석가는 실시간 데이터와 과거 시점의 데이터를 구분할 수 있습니다. 중요한 이유 데이터의 최신 상태를 확인하고 대시보드에서 오래된 데이터를 식별하는 데 도움이 됩니다. 확보 방법 ETL 스크립트 실행 시점의 시스템 시간입니다. 예시 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
결제 처리 활동
| 활동 | 설명 | ||
|---|---|---|---|
| 결제 승인 | 권한이 있는 사용자가 결제를 승인해 실행 단계로 진행할 수 있게 되는 주요 이정표입니다. 일반적으로 승인자가 시스템 사용자 인터페이스에서 조치를 취할 때 명시적 이벤트로 기록됩니다. | ||
| 중요한 이유 주요 확인 단계이며 병목이 자주 발생하는 지점입니다. 이 단계 전 대기 시간과 승인 주기를 분석하면 결제를 앞당길 기회를 찾을 수 있습니다. 확보 방법 승인 로그 테이블의 명시적 이벤트나 주 거래 테이블의 'Approved' 상태 변경을 확인합니다. 특정 사용자 조치 및 타임스탬프와 연결되어 있어야 합니다. 기록 권한이 있는 사용자가 시스템에서 승인 조치를 완료할 때 기록됩니다. 이벤트 유형 explicit | |||
| 결제 승인 완료 | 사람의 승인이 끝난 뒤 시스템이 결제를 승인하는 단계입니다. 자금을 확인하거나 사기 방지 규칙을 적용합니다. 명시적 로그 항목으로 기록되거나 실행 준비가 되었음을 나타내는 상태 변경으로 추론할 수 있습니다. | ||
| 중요한 이유 자금 이동 지시를 내리기 전의 중요한 통제 지점입니다. 이 단계의 지연은 시스템 성능 문제나 규정 준수 및 사기 검사 하위 시스템의 문제를 나타낼 수 있습니다. 확보 방법 시스템 처리 로그나 보안 로그의 명시적 기록을 확인합니다. 또는 상태가 'Approved'에서 'Authorized for Payment'로 변경된 기록을 통해 추론할 수 있습니다. 기록 최종 내부 검사를 통과한 뒤 시스템의 결제 엔진이 기록합니다. 이벤트 유형 explicit | |||
| 결제 오류 확인 | 시스템이 유효하지 않은 데이터나 규정 준수 경고 등 결제 과정의 문제를 감지했음을 나타냅니다. 일반적으로 관련 오류 코드와 함께 이벤트가 명시적으로 기록됩니다. | ||
| 중요한 이유 이 활동은 재작업 및 예외 처리 분석의 출발점입니다. '결제 실패 및 재작업 분석'과 '오류 해결 소요 시간' 대시보드에 반드시 필요합니다. 확보 방법 오류 로그 테이블의 명시적 기록이나 거래 테이블의 상태 변경('오류' 또는 '수정 필요')을 확인합니다. 이러한 이벤트는 결제 거래 ID와 연결해야 합니다. 기록 시스템의 검증 또는 처리 엔진이 오류를 감지하면 이벤트가 명시적으로 기록됩니다. 이벤트 유형 explicit | |||
| 결제 요청 생성 | 이 활동은 ACI Worldwide 시스템에서 새 결제 거래가 시작되는 시점을 나타냅니다. 일반적으로 사용자나 상위 시스템이 결제 요청을 제출할 때 명시적 이벤트로 기록되며, 고유 ID가 있는 새 거래 레코드가 생성됩니다. | ||
| 중요한 이유 결제 프로세스의 주요 시작 이벤트입니다. 이 활동부터 완료까지 걸리는 시간을 분석하면 전체 처리 시간을 확인할 수 있으며, 이는 프로세스 전반의 효율을 측정하는 데 중요합니다. 확보 방법 ACI의 핵심 거래 테이블이나 전용 이벤트 로그에 명시적 이벤트로 기록될 가능성이 높습니다. Payment Transaction ID와 연결된 생성 타임스탬프를 확인합니다. 기록 생성 레코드 또는 거래 로그의 명시적 'Create' 이벤트로 식별합니다. 이벤트 유형 explicit | |||
| 결제 정산 완료 | 결제 프로세스가 완료되고 수취인 계좌에 자금이 입금되었음을 최종 확인해 거래를 마무리하는 단계입니다. 결제 전체 흐름이 성공적으로 끝났음을 나타내는 중요한 이벤트입니다. | ||
| 중요한 이유 프로세스의 주요 성공 종료 이벤트입니다. 전체 처리 시간과 처리량을 계산하는 데 사용되며, 거의 모든 전 과정 성과 대시보드에 필요한 데이터입니다. 확보 방법 일반적으로 네트워크에서 최종 정산 확인 메시지를 받거나 내부 원장에 거래 완료가 반영될 때 명시적 이벤트로 기록됩니다. 기록 최종 정산 파일이나 메시지를 받으면 기록되며, 상태가 '정산 완료'로 변경됩니다. 이벤트 유형 explicit | |||
| 자금 이체 완료 | 결제 네트워크에서 지급인 계좌의 자금이 성공적으로 인출되었다는 확인을 받았음을 나타냅니다. 일반적으로 네트워크에서 수신한 상태 메시지로 기록됩니다. | ||
| 중요한 이유 외부 네트워크에서 결제가 성공적으로 실행되었음을 확인합니다. 정산 기간이 시작되는 시점이며 'Average Payment Settlement Time' KPI를 계산하는 데 중요한 데이터입니다. 확보 방법 결제 레코드를 업데이트하는 상태 메시지(예: SWIFT의 MT103 또는 ACH 확인 메시지)가 수신될 때 발생하는 명시적 이벤트입니다. 기록 청산 네트워크에서 외부 확인 메시지를 받으면 기록됩니다. 이벤트 유형 explicit | |||
| 결제 거부 | 승인자가 결제 요청을 거부하면 발생하며, 수정 후 다시 제출해야 하는 경우가 많습니다. 결제 진행을 멈추고 재처리 과정을 시작하는 명시적 이벤트입니다. | ||
| 중요한 이유 재처리와 프로세스 비효율을 파악합니다. 거부 빈도를 추적하면 초기 데이터 품질이나 제출 정책의 문제를 진단하고 재처리 분석을 지원할 수 있습니다. 확보 방법 승인 로그의 명시적 이벤트 또는 거래 테이블에서 상태가 'Rejected'로 변경된 기록으로 수집합니다. 거부 사유 코드가 이벤트에 포함될 수 있습니다. 기록 승인자가 시스템에서 거부 조치를 완료할 때 기록됩니다. 이벤트 유형 explicit | |||
| 결제 대사 완료 | ACI에 기록된 결제 거래를 은행 명세서 또는 원장 항목과 대조하는 최종 회계 단계입니다. 대사 모듈의 명시적 이벤트를 사용하거나 상태 변경을 바탕으로 추론할 수 있습니다. | ||
| 중요한 이유 이 활동으로 백오피스 대사 프로세스의 효율을 측정합니다. 지연되면 재무 보고의 정확성에 영향을 주고 미정산 결제 문제를 놓칠 수 있습니다. 확보 방법 ACI의 전용 대사 모듈이나 외부 ERP 시스템에서 정보를 가져올 수 있습니다. 결제 기록의 상태가 '대사 완료'로 변경된 내용으로 확인합니다. 기록 최종 상태가 '대사 완료'로 변경된 기록이나 결제 ID로 연결한 대사 데이터를 바탕으로 추론합니다. 이벤트 유형 inferred | |||
| 결제 승인 요청 | 결제가 초기 검증을 통과해 관리자 또는 재무 담당자의 승인을 받도록 전달되었음을 나타냅니다. 일반적으로 결제 워크플로의 상태 변경으로 기록됩니다. | ||
| 중요한 이유 승인 하위 프로세스가 시작되는 시점입니다. 이때부터 'Payment Approved'까지 걸리는 시간은 'Payment Approval Cycle Time Analysis' 대시보드에서 중요한 측정 항목입니다. 확보 방법 거래 데이터의 결제 상태 필드가 'Pending Approval'로 변경된 기록 등에서 도출합니다. 기록 타임스탬프와 함께 상태가 'Pending Approval' 또는 유사한 값으로 변경된 기록을 통해 추론합니다. 이벤트 유형 inferred | |||
| 결제 실패 | 복구할 수 없는 문제로 결제를 완료하지 못했음을 나타내는 최종 상태입니다. 해결 가능한 오류와는 구분되며, 결제가 최종적으로 실패한 상태를 의미합니다. | ||
| 중요한 이유 이 종료 이벤트를 추적하면 전체 결제 실패율을 계산할 수 있습니다. 실패 원인을 분석하면 데이터 품질과 프로세스 규칙을 개선하는 데 도움이 됩니다. 확보 방법 거래 데이터에서 '실패', '취소됨' 또는 '은행 거부'와 같은 최종 상태를 확인해 추론합니다. 이후 상태가 변경되지 않아야 합니다. 기록 결제 기록의 최종 실패 상태를 바탕으로 추론합니다. 이벤트 유형 inferred | |||
| 결제 오류 해결 | 사용자가 기존 오류를 수정하고 결제를 다시 처리하도록 제출한 시점을 나타냅니다. 결제 상태가 오류 상태에서 정상 처리 상태로 바뀌는 경우 이를 추론할 수 있습니다. | ||
| 중요한 이유 이 활동으로 예외 처리 과정이 마무리됩니다. '결제 오류 확인'부터 이 이벤트까지 걸린 시간이 오류 해결 소요 시간이며, 운영 효율을 측정하는 주요 지표입니다. 확보 방법 '오류' 상태에서 '승인 대기' 또는 '검증 완료'와 같은 처리 상태로 변경된 기록을 바탕으로 추론합니다. 사용자의 명시적 작업 로그를 사용할 수도 있습니다. 기록 오류 상태에서 다른 상태로 변경된 기록을 바탕으로 추론하며, 이는 오류가 수정되었음을 나타냅니다. 이벤트 유형 inferred | |||
| 결제 정보 검증 | 수취인 정보와 은행 코드 등 결제 정보가 올바른지 확인하는 자동 또는 수동 검사가 완료된 상태를 나타냅니다. 거래 상태가 'New'에서 'Validated' 또는 'Pending Approval'로 바뀐 기록을 통해 이 활동을 추론하는 경우가 많습니다. | ||
| 중요한 이유 초기 데이터 검증 단계의 효율을 추적합니다. 이 단계가 지연되면 앞단에 병목이 생기고 이후 프로세스에서 결제 오류가 발생할 가능성이 커질 수 있습니다. 확보 방법 주 결제 거래 테이블의 상태 변경 필드에서 추론합니다. 'Created' 상태와 이후 'Validated' 또는 유사한 상태의 타임스탬프를 비교합니다. 기록 예를 들어 결제 상태 필드가 'Entered'에서 'Validated'로 변경된 기록을 통해 추론합니다. 이벤트 유형 inferred | |||
| 결제 지시 전송 | 결제 지시를 작성해 SWIFT, ACH, SEPA와 같은 외부 결제 네트워크로 전송하는 시점을 나타냅니다. ACI 시스템은 감사와 추적을 위해 이 인계 과정을 명시적으로 기록합니다. | ||
| 중요한 이유 많은 결제 유형에서 되돌리기 어려운 시점입니다. 이 시점을 추적하면 외부 의존성이 개입하기 전까지의 내부 처리 시간을 측정할 수 있습니다. 확보 방법 대부분 ACI의 거래 로그나 메시지 로그에 명시적 이벤트로 기록되며, 네트워크별 참조 번호가 포함되는 경우가 많습니다. 기록 결제 메시지가 외부 네트워크로 전송될 때 명시적 로그 항목이 생성됩니다. 이벤트 유형 explicit | |||
| 결제 확인 | 결제가 성공적으로 처리되고 확인 메시지를 받았음을 내부적으로 확인하는 단계입니다. 수취인이나 다른 내부 시스템에 알리는 계기가 되는 경우가 많습니다. | ||
| 중요한 이유 기한 준수 여부와 기한 내 결제율을 측정하는 데 중요한 이정표입니다. 조직이 결제 실행을 완료된 것으로 판단한 시점을 명확한 타임스탬프로 제공합니다. 확보 방법 외부 네트워크의 확인을 받은 뒤 결제 거래 테이블의 상태가 'Confirmed' 또는 'Completed'로 바뀐 기록을 통해 추론하는 경우가 많습니다. 기록 상태가 'Confirmed' 또는 'Processed'로 변경된 기록을 통해 추론합니다. 이벤트 유형 inferred | |||
데이터 추출 가이드
단계
데이터베이스 환경에 접속합니다: SQL Server Management Studio(SSMS) 또는 호환 클라이언트를 사용해 ACI Postilion Realtime 데이터베이스가 있는 SQL Server 인스턴스에 로그인합니다.
주요 테이블을 확인합니다:
post_tran(거래 로그) 및post_tran_cust(사용자 지정 데이터 확장) 테이블을 찾습니다. 해당 개체에 대한SELECT권한이 있는지 확인합니다.사례 식별자를 정합니다: 이 추출에서는
retrieval_reference_nr을PaymentTransactionId로 사용합니다. 구현 환경에서system_trace_audit_nr와transmission_date_time을 조합하는 등 다른 고유 키를 사용한다면 쿼리의 선택 항목을 조정합니다.필터 매개변수를 설정합니다: 아래 쿼리를 엽니다. 스크립트 상단에서
@StartDate및@EndDate변수를 찾아 원하는 추출 기간(예: 최근 30~90일)으로 설정해 성능을 최적화합니다.활동 로직을 검토합니다: 쿼리는 ISO 8583 메시지 유형(예: 0200, 0210)과 응답 코드를 필수 process mining 활동 14개에 매핑합니다.
CASE문이 ACI 인터페이스 설정에 맞는지 확인합니다.쿼리를 실행합니다: 전체 스크립트를 실행합니다. 쿼리는
UNION ALL을 사용해 서로 다른 거래 상태를 하나의 이벤트 로그 형식으로 정규화합니다.출력 데이터를 확인합니다:
PaymentTransactionId,ActivityName,EventTimestamp열이 있는지 확인합니다. 중요한 필드에 예상치 못한NULL값이 없는지도 확인합니다.데이터를 내보냅니다: SSMS 결과 그리드를 마우스 오른쪽 버튼으로 클릭하고 결과를 CSV 파일(예:
ACI_Payments_EventLog.csv)로 저장합니다.ProcessMind에 맞게 형식을 확인합니다: CSV를 열어
EventTimestamp가 표준 형식(YYYY-MM-DD HH:MM:SS)인지,PaymentAmount에 숫자만 포함되어 있는지 확인합니다.업로드합니다: 확인한 CSV를 ProcessMind로 가져오고 각 열을 사례 ID, 활동, 타임스탬프에 매핑합니다.
구성
- 날짜 범위: ACI
post_tran테이블은 빠르게 커집니다. 추출 기간은 3개월 단위로 제한하거나, 가능한 경우 파티션 전환을 사용하는 것이 좋습니다. - 응답 코드: 쿼리는
rsp_code = '00'을 성공으로 간주합니다. 기관에서 승인/성공에 다른 코드(예: '08' 또는 '10')를 사용한다면 필터를 수정합니다. - 메시지 유형(ISO 8583): 스크립트는 표준 메시지 유형(요청은 0100/0200, 응답은 0210)을 사용합니다.
source_node_name설정에 정의된 사용자 지정 메시지 유형은 조정이 필요할 수 있습니다. - 시스템 성능: 이 쿼리는 운영 중인 거래 처리가 차단되지 않도록
NOLOCK힌트를 사용합니다. 운영 환경에서는 이 힌트를 제거하지 마세요. - 통화: 금액은 원시 값으로 추출됩니다. 분석 중 여러 통화를 정규화해야 한다면
tran_currency_code를 사용하세요.
샘플 쿼리 sql
DECLARE @StartDate DATETIME = '2023-01-01 00:00:00';
DECLARE @EndDate DATETIME = '2023-01-31 23:59:59';
/* 1. Payment Request Created: Initial transaction request received */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Request Created' AS ActivityName,
t.datetime_req AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Origination' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200') -- Authorization/Financial Request
UNION ALL
/* 2. Payment Details Validated: Inferred after request but before routing */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Details Validated' AS ActivityName,
DATEADD(second, 1, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Compliance' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200')
AND t.rsp_code = '00' -- Implies validation passed
UNION ALL
/* 3. Payment Sent For Approval: Routing to internal authorization */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Sent For Approval' AS ActivityName,
DATEADD(second, 2, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200')
AND t.tran_amount_req > 1000 -- Example threshold for approval logic
UNION ALL
/* 4. Payment Approved: Successful response code logic */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Approved' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Approver' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type IN ('0110', '0210')
UNION ALL
/* 5. Payment Rejected: Specific rejection codes */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Rejected' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code IN ('51', '05', '61') -- Insufficient funds, Do not honor, etc.
UNION ALL
/* 6. Payment Authorized: Successful authorization completion */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Authorized' AS ActivityName,
DATEADD(millisecond, 500, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0110' -- Authorization Response
UNION ALL
/* 7. Payment Instruction Sent: Handoff to Sink Node */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Instruction Sent' AS ActivityName,
DATEADD(second, 1, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
t.sink_node_name AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Network Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.sink_node_name IS NOT NULL
AND t.message_type IN ('0200', '0100')
UNION ALL
/* 8. Funds Transferred: External network confirmation */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Funds Transferred' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
t.sink_node_name AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Treasury' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210' -- Financial Response
UNION ALL
/* 9. Payment Confirmed: Final acknowledgment */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Confirmed' AS ActivityName,
DATEADD(second, 5, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Customer Service' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210'
UNION ALL
/* 10. Payment Settled: Settlement/Reconciliation message */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Settled' AS ActivityName,
ISNULL(t.settle_date, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Settlement Engine' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Accounting' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type = '0500' -- Reconciliation
AND t.rsp_code = '00'
UNION ALL
/* 11. Payment Failed: System Errors */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Failed' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'IT Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code IN ('91', '96', '06') -- Issuer down, System malfunction
UNION ALL
/* 12. Payment Error Identified: General Error */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Error Identified' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Compliance' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code NOT IN ('00')
AND t.message_type IN ('0210', '0110')
UNION ALL
/* 13. Payment Error Resolved: Reversal or Correction followed by Success */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Error Resolved' AS ActivityName,
t.datetime_req AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0400', '0420') -- Reversal/Advice
UNION ALL
/* 14. Payment Reconciled: Batch processing flag from Custom Table */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Reconciled' AS ActivityName,
ISNULL(c.recon_date, DATEADD(hour, 24, t.datetime_req)) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Recon Module' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Finance' AS Department
FROM post_tran t WITH (NOLOCK)
JOIN post_tran_cust c WITH (NOLOCK) ON t.post_tran_cust_id = c.post_tran_cust_id
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210'
AND c.recon_date IS NOT NULL; 시작할 준비가 되셨나요?
이 템플릿을 참고해 결제 처리 데이터 추출을 시작하세요. 지금 금융 워크플로에서 유용한 분석 결과를 얻고 효율을 높여 보세요.
결제 처리를 간소화하세요. 지금 무료 체험을 시작하세요
결제 예외를 줄이고 98%의 자동 직결 처리를 달성하세요.
신용카드가 필요하지 않으며, 몇 분이면 설정할 수 있습니다.