레거시 메인프레임에 API 우선 KYC 통합하기 (KO)

격차 해소API 게이트웨이 및 미들웨어를 활용하여 최신 API 우선 KYC 플랫폼과 레거시 메인프레임 애플리케이션 간에 안전하고 성능 좋은 다리를 만드세요.

전략적 단계별 접근비판적이지 않은 데이터 동기화부터 시작하여 점진적으로 실시간 검증 프로세스로 확장하여 중단을 최소화하는 단계별 통합 접근 방식을 채택하세요.

데이터 변환최신 JSON/REST API와 기존 메인프레임 데이터 구조 간의 상이한 데이터 형식을 조정하기 위해 강력한 데이터 변환 및 매핑 계층을 구현하세요.

보안 우선민감한 KYC 데이터를 메인프레임에 연결할 때 데이터 무결성 및 규제 준수를 유지하기 위해 강력한 인증, 암호화 및 감사 로깅을 우선시하세요.

현대적인 API 우선 신원 확인(KYC) 솔루션을 레거시 메인프레임 시스템에 통합하는 것은 대기업에게 고유한 과제를 제시합니다. 메인프레임은 많은 금융 기관, 정부 기관 및 대기업에서 중요한 운영의 중추로 남아 있지만, 그 아키텍처는 종종 API 경제 이전에 만들어졌습니다. 이 블로그 게시물은 기존 인프라를 완전히 개편하지 않고도 강력한 신원 확인 및 규정 준수를 가능하게 하면서 이 격차를 성공적으로 해소하기 위한 실용적인 전략과 아키텍처 고려 사항을 탐구합니다.

과제 이해: 레거시 메인프레임 및 API 우선 KYC

메인프레임은 탁월한 안정성, 보안 및 처리 능력으로 유명하며 매일 수십억 건의 트랜잭션을 처리합니다. 그러나 COBOL, PL/I, CICS, IMS 또는 VSAM을 기반으로 하는 기존 인터페이스는 Didit과 같은 최신 KYC 솔루션을 정의하는 RESTful API 패러다임에 기본적으로 설계되지 않았습니다. API 우선 KYC 플랫폼은 일반적으로 JSON 또는 XML 형식으로 데이터를 반환하는 간단한 API 호출을 통해 실시간 신원 확인, 생체 인식 인증 및 AML 심사를 제공합니다.

메인프레임 통합의 주요 과제는 다음과 같습니다.

• 프로토콜 불일치: HTTP/REST와 기존 메인프레임 통신 프로토콜(예: SNA, MQ, 독점 형식의 TCP/IP 소켓) 간의 변환.
• 데이터 형식 비호환성: 메인프레임의 구조화된 데이터(예: EBCDIC, 고정 길이 레코드)를 최신 형식(예: ASCII, JSON)으로 변환하고 그 반대로 변환.
• 보안 및 인증: 분산 시스템과 고도로 통제된 메인프레임 환경 간의 안전하고 감사 가능한 액세스 보장.
• 성능 및 지연 시간: 메인프레임 트랜잭션과 실시간 KYC 확인 모두에서 기대되는 고성능 및 낮은 지연 시간 유지.
• 복잡성 및 기술 격차: 메인프레임 개발에 필요한 전문 지식과 이기종 시스템 통합의 본질적인 복잡성.

메인프레임 통합을 위한 아키텍처 패턴

성공적인 통합은 두 환경 간을 중재할 수 있는 중간 계층을 설정하는 데 달려 있습니다. 다음은 일반적인 아키텍처 패턴입니다.

1. ESB(Enterprise Service Bus)가 있는 API 게이트웨이

API 게이트웨이는 모든 API 요청의 진입점 역할을 하며 보안, 속도 제한 및 라우팅을 제공합니다. ESB(또는 최신 통합 플랫폼)는 게이트웨이 뒤에 위치하여 프로토콜 변환, 데이터 변환 및 메인프레임과의 오케스트레이션과 같은 복잡한 작업을 처리합니다. 이 패턴은 매우 유연하고 확장성이 뛰어납니다.

작동 방식:

1. 최신 애플리케이션(예: 신규 고객 온보딩 포털)은 API 우선 KYC 솔루션(예: Didit의 API)을 호출하여 신원을 확인합니다.
2. 성공적으로 확인되면 애플리케이션은 메인프레임의 고객 레코드를 업데이트해야 합니다. 엔터프라이즈의 내부 API 게이트웨이로 요청을 보냅니다.
3. API 게이트웨이는 요청을 ESB로 라우팅합니다.
4. ESB는 API의 JSON 페이로드를 메인프레임 호환 형식(예: COBOL 카피북 구조)으로 변환합니다.
5. ESB는 메인프레임 커넥터(예: IBM MQ, CICS Transaction Gateway 또는 사용자 지정 TCP/IP 소켓 프로그램)를 사용하여 메인프레임 애플리케이션과 통신합니다.
6. 메인프레임은 요청을 처리하고 ESB로 응답을 다시 보내고, ESB는 이를 호출하는 애플리케이션을 위해 JSON으로 다시 변환합니다.

2. 메시지 큐(예: IBM MQ)

비동기 처리의 경우 메시지 큐는 매우 중요합니다. 이 접근 방식은 시스템을 분리하여 복원력을 향상시키고 배치 처리 또는 지연된 업데이트를 허용합니다. 이는 초기 데이터 동기화 또는 덜 시간에 민감한 KYC 업데이트에 특히 유용합니다.

작동 방식:

1. 최신 애플리케이션은 API 우선 솔루션을 사용하여 KYC 프로세스를 시작합니다.
2. KYC가 완료되면 애플리케이션은 IBM MQ 큐에 메시지(예: 고객 ID, 확인 상태)를 배치합니다.
3. 메인프레임 애플리케이션(예: CICS 프로그램)은 이 큐를 지속적으로 모니터링하고 메시지를 검색하고 처리하며 관련 메인프레임 데이터베이스(예: DB2, VSAM)를 업데이트합니다.
4. 선택적으로 메인프레임은 최신 애플리케이션이 사용할 수 있도록 다른 큐에 응답 메시지를 다시 배치할 수 있습니다.

3. 직접 메인프레임 커넥터/어댑터

일부 통합 플랫폼 및 사용자 지정 솔루션은 CICS 트랜잭션, IMS 데이터베이스 또는 VSAM 파일과 같은 메인프레임 리소스와 상호 작용할 수 있는 직접 커넥터를 제공합니다. 이러한 커넥터는 프로토콜 및 데이터 형식 복잡성의 많은 부분을 추상화합니다.

예: CICS Transaction Gateway(CTG)를 사용하여 KYC 확인 결과에 따라 고객 레코드 업데이트를 처리하는 메인프레임의 COBOL 프로그램을 호출합니다.

API 우선 KYC 통합을 위한 실제 단계

1. 통합 범위 및 데이터 흐름 정의

어떤 KYC 데이터 포인트가 메인프레임과 동기화되어야 하는지, 어떤 방향으로 동기화되어야 하는지 명확하게 매핑합니다. 단방향(예: KYC 상태를 메인프레임으로)인지 양방향(예: KYC를 위한 메인프레임 데이터 보강)인지 확인합니다. 영향을 받을 특정 메인프레임 애플리케이션 및 데이터 저장소를 식별합니다.

2. 데이터 변환 및 매핑 구현

이는 종종 가장 복잡한 단계입니다. 최신 JSON/XML 구조와 메인프레임 데이터 레이아웃(예: COBOL 카피북) 간에 변환할 수 있는 서비스를 개발해야 합니다. 문자 집합 변환(ASCII에서 EBCDIC로) 및 데이터 유형 매핑을 위해 도구 또는 사용자 지정 코드가 필요합니다.

예(변환을 위한 의사 코드):

// API 우선 KYC에서 들어오는 JSON
{
  "externalId": "CUST12345",
  "kycStatus": "APPROVED",
  "amlCheck": "CLEARED",
  "verificationDate": "2023-10-27T10:30:00Z"
}

// 대상 COBOL 구조
01 CUSTOMER-KYC-RECORD.
   05 CUST-EXTERNAL-ID  PIC X(15).
   05 CUST-KYC-STATUS   PIC X(10).
   05 CUST-AML-STATUS   PIC X(10).
   05 CUST-VERIF-DATE   PIC 9(8).  "YYYYMMDD"

통합 계층은 JSON을 구문 분석하고 값을 추출하고 날짜 형식을 변환하며 메인프레임으로 보내기 전에 COBOL 구조의 해당 필드를 채웁니다.

3. 통합 지점 보안

메인프레임 보안은 가장 중요합니다. 모든 통신 채널에 대해 강력한 인증(예: Kerberos, RACF), 권한 부여(ACL) 및 암호화(TLS/SSL)를 구현합니다. 최신 통합 계층과 메인프레임 애플리케이션 간의 모든 상호 작용에 대한 자세한 감사 추적이 유지되도록 합니다.

4. 성능 및 멱등성 처리

높은 처리량과 낮은 지연 시간을 위해 설계합니다. 연결 풀링을 사용하고 데이터 페이로드를 최적화하며 적절한 경우 캐싱을 구현합니다. 반복된 요청(예: 네트워크 문제로 인한)이 메인프레임에서 데이터 중복 또는 잘못된 상태로 이어지지 않도록 합니다(멱등성).

5. 단계별 출시 및 모니터링

파일럿 프로그램 또는 중요하지 않은 통합으로 시작합니다. 성능, 오류율 및 데이터 일관성을 면밀히 모니터링합니다. 피드백 및 성능 메트릭을 기반으로 범위를 점진적으로 확장합니다. 통합 계층 및 메인프레임 애플리케이션 모두에 대한 포괄적인 로깅 및 경고를 구현합니다.

Didit이 도움이 되는 방법

Didit은 모든 기술 스택에 원활하게 통합되도록 설계된 API 우선 신원 확인 플랫폼을 제공합니다. 당사의 RESTful API 및 포괄적인 SDK는 고급 KYC, AML 심사 및 생체 인식 인증을 기존 시스템에 통합하는 것을 간단하게 만듭니다. 메인프레임 환경의 경우 Didit의 모듈식 아키텍처는 필요한 특정 확인 결과만 사용할 수 있도록 하여 데이터 변환 프로세스를 단순화합니다. 당사의 광범위한 문서 및 개발자 친화적인 도구는 통합 프로세스를 가속화하여 기업이 기존 메인프레임 인프라를 존중하면서 최신 신원 확인 기능을 활용할 수 있도록 합니다.

시작할 준비가 되셨습니까?

API 우선 KYC 솔루션과 레거시 메인프레임 간의 격차를 해소하는 것은 복잡하지만 달성 가능한 노력입니다. 전략적 아키텍처 패턴을 채택하고 데이터 변환에 집중하며 보안을 우선시함으로써 기업은 안정적인 핵심 시스템을 포기하지 않고 규정 준수 프로세스를 현대화할 수 있습니다. 당사의 API 우선 접근 방식이 통합 여정을 어떻게 단순화할 수 있는지 알아보려면 Didit의 기술 문서를 살펴보세요. 더 자세한 정보나 맞춤형 상담을 원하시면 지금 영업팀에 문의하세요.

자주 묻는 질문

Q: API 우선 KYC를 메인프레임과 통합할 때 가장 큰 과제는 무엇입니까?
A: 주요 과제는 프로토콜 및 데이터 형식 불일치, 강력한 보안 보장, 성능 유지, 최신 분산 시스템과 고도로 전문화된 레거시 메인프레임 환경 간의 연결 복잡성 극복입니다.

Q: 메인프레임 통합에 기존 API 게이트웨이를 사용할 수 있습니까?
A: 예, 기존 API 게이트웨이는 중요한 구성 요소가 될 수 있습니다. 외부 API 노출, 보안 및 라우팅을 처리하여 메인프레임 자체에서 이러한 문제를 덜어줄 수 있습니다. 그런 다음 일반적으로 요청을 ESB 또는 메인프레임과 통신하는 사용자 지정 통합 계층으로 라우팅합니다.

Q: 메인프레임과의 실시간 KYC 통합이 가능합니까?
A: 예, 실시간 통합은 특히 CICS Transaction Gateway 또는 직접 웹 서비스 호출(z/OS Connect와 같은 도구를 통해 메인프레임이 지원하는 경우)과 같은 동기 통신 메커니즘을 사용할 때 가능합니다. 그러나 지연 시간을 관리하고 메인프레임 트랜잭션 무결성을 보장하기 위해서는 신중한 설계가 필요합니다.

Q: KYC를 메인프레임과 통합할 때 데이터 상주 및 규정 준수는 어떻습니까?
A: 데이터 상주 요구 사항을 신중하게 고려해야 합니다. API 우선 KYC 공급자(Didit과 같은)가 필요한 지역에서 데이터 처리를 제공하는지 확인하십시오. 메인프레임으로 이동하는 데이터의 경우 강력한 암호화를 구현하고 통합 파이프라인 전체에서 모든 관련 데이터 보호 규정(예: GDPR, CCPA)을 준수하십시오.