자금 관리 팀의 수작업 지급 재입력과 명세서 대사
많은 자금 관리 팀이 은행 포털에 지급을 입력하고, 은행마다 다른 형식의 거래 명세서를 수집하며, 월말에 스프레드시트로 계좌를 대사합니다. 모든 수작업 단계는 지연과 비용을 낳고, 사기나 오류가 생길 기회입니다.
은행들도 기존 SWIFT MT 형식보다 더 풍부한 구조화 데이터를 담는 국제 금융 메시지 표준 ISO 20022로 이동하고 있습니다. 이를 생성하고 읽지 못하는 시스템은 은행보다 뒤처집니다.
고객에게 달라지는 것
자동 처리
승인된 지급 실행이 서명된 파일이나 API 호출로 ERP를 떠나고, 명세서는 ERP가 스스로 대사할 수 있는 형태로 돌아옵니다.
더 빠른 마감
수동 CSV 업로드와 월말 스프레드시트 조정 대신 매일 실행되는 다중 통화 대사.
모든 예외에 담당자 지정
거절된 지급과 미매칭 항목이 사유와 함께 데드레터 예외 대기열에 도착하며, 메일함에서 사라지지 않습니다.
제공하는 것
호스트 간 및 은행 직접 연결
은행과 국가별로 선택한 SFTP, EBICS, SWIFT 연결, 오픈 뱅킹 및 은행 직접 API.
지급 파일 생성
지급 실행에서 만든 ISO 20022 pain.001 지급 파일을 각 은행의 변형에 맞게 검증하고 은행이 요구하는 방식으로 서명하거나 암호화합니다.
상태 및 거절 처리
pain.002 상태 보고서를 다시 읽어 모든 지급이 은행 사유 코드와 함께 수락·거절·대기 상태로 표시됩니다.
명세서 수집
camt.053 및 MT940 일 마감 명세서와 일중 보고서를 수집하고 누락과 중복을 확인해 ERP에 적재합니다.
은행 및 핀테크를 위한 은행 간 메시징
금융 기관 간 신용 이체와 상태를 위한 pacs 메시지를 코어 뱅킹 원장과 연결합니다.
다중 통화 대사
통화와 계좌 전반에서 미결 항목을 자동으로 정리하고 나머지는 예외 대기열로 보내는 매칭 규칙.
은행 테스트 증거와 런북
각 은행의 테스트 케이스를 실행해 감사인을 위해 기록하고, 파일 누락, 이체 실패, 만료 예정 키 또는 인증서에 대한 경보를 제공합니다.
업무 방식
은행과 흐름 매핑
현재 은행, 계좌, 지급 유형, 수작업 단계를 목록화하고 어떤 흐름을 먼저 할지 합의합니다.
형식별 명세
각 은행의 구현 가이드를 기준으로 서명, 암호화, 파일 명명을 포함한 매핑을 작성합니다.
커넥터 구축
지급 내보내기, 상태 가져오기, 명세서 가져오기, 매칭을 구축하고 모든 형식에 자동 테스트를 붙입니다.
은행별 테스트
은행 테스트 환경에서 합의된 테스트 케이스를 실행하고 은행 검증에서 거절되는 부분을 수정합니다.
은행별 순차 전환
한 번에 한 은행씩 전환하고, 새 흐름이 검증될 때까지 기존 프로세스를 대체 수단으로 유지합니다.
모니터링과 지원
이체, 키, 인증서 만료를 감시하고 은행이 형식 변경을 공지하면 대비합니다.
옆으로 스크롤하여 전체 그림을 확인하십시오.
ERP에서 은행으로: 결제는 나가고, 거래 명세서는 들어옵니다
승인된 결제는 서명된 ISO 20022 파일로 호스트 간 채널을 통해 ERP를 떠납니다. 상태 보고서와 거래 명세서도 같은 경로로 돌아와 미결 항목과 대사됩니다. 거절된 결제와 미매칭 항목은 사유와 함께 귀사 팀에 전달됩니다.
- 기본 흐름
- 비동기
- 예외 경로
10단계로 된 흐름
단계별 흐름
- ERP에서 통합 계층로: 승인된 결제 배치, REST/JSON · IDoc 사용 (기본 흐름).
- 통합 계층에서 보안 은행 채널로: 서명 및 암호화된 지급 파일, ISO 20022 pain.001 · OpenPGP 사용 (기본 흐름).
- 보안 은행 채널에서 은행로: 은행으로 전송됨, SFTP H2H 사용 (기본 흐름).
- 은행에서 보안 은행 채널로: 상태 보고서 및 거래 명세서, pain.002 · camt.053 · MT940 사용 (비동기).
- 보안 은행 채널에서 통합 계층로: 수집 및 검증됨, SFTP H2H 사용 (비동기).
- 통합 계층에서 대사 엔진로: 거래 명세서 항목, camt.053 사용 (비동기).
- 대사 엔진에서 ERP로: 매칭된 전기 처리, REST/JSON 사용 (기본 흐름).
- 통합 계층에서 자금 관리 및 재무 팀로: 거절된 결제, 사유 코드 포함, pain.002 RJCT 사용 (예외 경로).
- 대사 엔진에서 자금 관리 및 재무 팀로: 미매칭 항목: 대사 불일치 (예외 경로).
- 자금 관리 및 재무 팀에서 ERP로: 수정 후 재제출 (예외 경로).
옆으로 스크롤하여 전체 그림을 확인하십시오.
오픈 뱅킹: 고객 동의 기반의 데이터와 결제
고객이 동의하면 커넥터가 토큰을 보관하고, 은행에 대한 모든 호출이 승인되고 기록됩니다. 동의가 만료되거나 철회되면 앱이 조용히 실패하지 않고 고객에게 다시 요청합니다.
- 기본 흐름
- 비동기
- 예외 경로
7단계로 된 흐름
단계별 흐름
- 고객에서 귀사 앱 또는 플랫폼로: 동의 부여 (기본 흐름).
- 귀사 앱 또는 플랫폼에서 오픈 뱅킹 커넥터로: 계좌 및 결제 요청, REST/JSON 사용 (기본 흐름).
- 오픈 뱅킹 커넥터에서 은행 API 또는 애그리게이터로: 승인된 API 호출, OAuth 2.0 · FAPI · REST 사용 (기본 흐름).
- 은행 API 또는 애그리게이터에서 오픈 뱅킹 커넥터로: 잔액, 거래, 결제 상태, REST/JSON · webhook 사용 (비동기).
- 오픈 뱅킹 커넥터에서 ERP 또는 원장로: 정규화된 거래, REST/JSON 사용 (기본 흐름).
- 은행 API 또는 애그리게이터에서 오픈 뱅킹 커넥터로: 동의 만료 또는 철회, HTTP 401 · 403 사용 (예외 경로).
- 오픈 뱅킹 커넥터에서 귀사 앱 또는 플랫폼로: 고객에게 동의 갱신 요청 (예외 경로).
표준, 형식, 채널
표준만이 아니라 각 은행의 구현 가이드를 기준으로 구축합니다. 제품명을 언급한다고 해서 해당 벤더와 파트너십이 있는 것은 아닙니다.
- 은행 표준 및 채널
- ISO 20022
- pain.001
- pain.002
- camt.052
- camt.053
- camt.054
- MT940
- MT942
- Swift
- EBICS
- SFTP (H2H)
- OpenPGP
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
운영 환경에서의 입증
걸프 지역 Tier-1 은행 및 역내 대기업을 위해 SAP S/4HANA를 ISO 20022 기반 역내 은행 결제 인프라와 연결했습니다. 지급은 서명되고, 예외는 데드레터 큐로 이동하며, 은행 계좌 전반의 대사는 자동입니다.
시작 방법
은행과 형식 요구가 명확하면 바로 제안서로 진행합니다. 여러 은행, 국가 또는 문서화되지 않은 레거시 인터페이스가 있으면 보통 블루프린트 스튜디오나 브라운필드 진단 브리지에서 시작합니다.
다음 단계
사전 컨설팅 세션
무료 30분 온라인 사전 컨설팅 세션에서 목표, 시스템, 제약 조건을 함께 검토합니다.
준비도 검토
무료 48시간 준비도 검토에서 프린시펄 아키텍트가 프로젝트를 6개 항목의 준비 완료 정의에 비추어 점검하고 적합한 트랙을 권고합니다.
트랙 선택
범위가 준비된 프로젝트는 영업일 기준 3~5일 이내 구속력 있는 제안서를 받습니다. 개념 단계 프로젝트는 블루프린트 스튜디오에서 시작합니다. 장애가 있거나 문서화되지 않았거나 통합이 필요한 운영 시스템은 1~2주 진단으로 시작합니다. 블루프린트 스튜디오와 진단은 각각 고정 비용이며 제안서에 명시됩니다.
5단계 수행
착수 준비, 라이브 시연이 포함된 스프린트, 통합 및 강화, 수용 및 오픈, 이후 관리형 서비스 순으로 진행합니다. 오픈 후에는 보증 기간, 이후 선택형 지원 및 유지보수이 이어집니다.
질문과 답변
ISO 20022란 무엇이며 왜 중요합니까?
ISO 20022는 국제 금융 메시지 표준입니다. XML 메시지는 기존 SWIFT MT 형식이 담지 못하는 전체 이름, 주소, 송금 세부 정보 같은 구조화 데이터를 담습니다. 은행과 결제 시스템이 이 표준으로 이동했으므로, 이를 기반으로 만든 지급 및 명세서 파일은 대사가 더 정확해지고 규정 준수 검사를 더 자주 통과합니다.
어떤 은행 형식과 채널을 다룹니까?
지급에는 pain.001, 상태에는 pain.002, 계좌 보고에는 camt.052·camt.053·camt.054, 은행 간에는 pacs 메시지를 사용합니다. 많은 은행이 여전히 보내는 MT940 및 MT942 명세서도 읽습니다. 전송은 호스트 간 SFTP, EBICS, SWIFT, 은행 API를 사용합니다. 은행마다 각 형식의 변형이 있으므로 해당 은행의 구현 가이드를 기준으로 구축합니다.
어떤 ERP를 은행과 연결할 수 있습니까?
SAP S/4HANA, Oracle Fusion Cloud ERP와 NetSuite, Microsoft Dynamics 365, Odoo, Sage, 그리고 자금 관리 및 맞춤 시스템을 연결합니다. ERP에 자체 은행 통신 모듈이 있으면 이를 우회하지 않고 구성하고 확장합니다.
지급 파일 보안은 어떻게 유지합니까?
지급 파일은 각 은행이 요구하는 방식으로 서명·암호화되고 합의된 채널로만 전송됩니다. 키와 인증서는 코드가 아니라 고객의 키 보관소나 하드웨어 보안 모듈에 보관합니다. 파일은 전송 전에 검증되고 모든 이체가 기록되어 각 지급을 누가 승인하고 보냈는지 추적할 수 있습니다.
명세서 항목이 매칭되지 않으면 어떻게 합니까?
가능성 있는 후보와 매칭되지 않은 이유(금액 차이, 참조 누락 등)를 함께 검토 목록으로 보냅니다. 고객 팀이 그곳에서 처리하고, 같은 사례가 다음에 매칭되도록 규칙을 조정할 수 있습니다. 고객이 승인한 매칭 없이는 원장에 전표 처리되지 않습니다.
은행 통합의 속도를 결정하는 것은 무엇입니까?
대부분 코드가 아니라 은행입니다. 은행마다 온보딩 단계, 테스트 기간, 승인이 다르고, 일부는 테스트 전에 계약이나 키 교환이 필요합니다. 매핑 단계 후 은행별 계획을 제공하고 준비된 은행부터 테스트를 시작합니다.
은행이 형식을 변경하면 어떻게 합니까?
은행은 SWIFT MT에서 ISO 20022로 이동할 때처럼 형식 변경을 사전에 공지합니다. 우리는 연결된 은행의 공지를 추적하고 영향을 평가하며, 기한 전에 은행과 변경 및 테스트 일정을 잡습니다.
구축할 준비가 되셨습니까? 제안서를 요청하십시오.
요구사항이나 RFP를 보내 주십시오. 아키텍트가 검증한 뒤 구속력 있는 고정 범위 제안서를 보내 드립니다.
다음 단계
준비도 검토
무료 48시간 준비도 검토에서 프린시펄 아키텍트가 프로젝트를 6개 항목의 준비 완료 정의에 비추어 점검하고 적합한 트랙을 권고합니다.
구속력 있는 제안서
무상 아키텍처 검증 후 영업일 기준 3~5일 이내 구속력 있는 고정 범위 제안서를 받습니다. 마일스톤, 아키텍처, 팀 구성, SLA를 담습니다. 요구사항을 공유하기 전에 요청 시 비밀유지계약(NDA)을 체결합니다.
착수 준비
계약에 서명하시면 엔지니어링 포드가 계약 체결 후 영업일 기준 5~10일 이내 스프린트 0을 시작합니다.
5단계 수행
착수 준비, 라이브 시연이 포함된 스프린트, 통합 및 강화, 수용 및 오픈, 이후 관리형 서비스 순으로 진행합니다. 오픈 후에는 보증 기간, 이후 선택형 지원 및 유지보수이 이어집니다.