본문으로 건너뛰기
XSIS
금융 지구의 사무용 빌딩들

산업

핀테크 및 금융 서비스

실시간 정확성과 규제 감독을 위해 연결된 은행, 결제, 원장.

금융 상품이 연결 지점에서 실패하는 이유

금융 상품은 하나의 시스템인 경우가 거의 없습니다. 코어 원장, 카드 처리, 신원 확인, 사기 심사, 결제 인프라, 그리고 그 뒤의 ERP로 구성됩니다. 어려운 부분은 이들 사이의 연결과 그중 하나가 실패할 때 벌어지는 일입니다. 우리는 그 연결을 먼저 설계하고, 실패 경로를 문서로 남깁니다.

  • 엄격한 규제 마감

    사우디 ZATCA 2단계와 UAE PINT-AE 같은 전자 인보이스 의무, DORA 같은 복원력 규정이 정해진 날짜에 적용됩니다.

  • 외부로 나갈 수 없는 데이터

    규제 대상 은행은 고객 정보나 금융 기록을 해외 퍼블릭 AI 서비스로 보낼 수 없습니다.

  • 수작업 대사

    은행, 프로세서, ERP 사이에는 여전히 배치 파일과 스프레드시트가 남아 있습니다.

달라지는 점

  1. 실시간 원장 정확성

    모든 전기, 수수료, 정산을 자동으로 대사하고 예외는 사람에게 전달합니다.

  2. 규제 감독에 대한 준비

    운영 전에 접근 권한을 제한·기록하고 모든 변경을 추적할 수 있습니다.

  3. 소버린 AI

    데이터가 외부로 나가지 않고 귀사 환경 안에서 작동하는 문서 AI와 어시스턴트.

황혼의 두바이 스카이라인, 운하에서 바라본 모습

우리의 핵심 전문 분야

핀테크는 우리의 핵심 산업입니다. 은행, 결제 회사, 대출 기관, 자산 운용사, 보험사, 지갑 사업자가 운영하는 소프트웨어를 구축하고 통합하며, 이 시스템들이 사용하는 표준을 잘 알고 있습니다. ISO 20022, ISO 8583, EMV, 오픈 뱅킹 API, 그리고 은행이 여전히 의존하는 파일 형식이 그 예입니다.

우리는 규제 환경에 맞춰 엔지니어링합니다. 접근 권한은 제한하고 기록하며, 민감한 데이터는 있어야 할 필요가 없는 곳에 두지 않고, 모든 변경을 추적할 수 있습니다. 귀사의 컴플라이언스 및 위험 팀은 시스템이 오픈된 뒤가 아니라 오픈 전에 작동 방식을 확인합니다.

은행 창구 직원이 고객과 함께 현금을 세고 있습니다

우리가 일하는 분야

우리가 구축하는 것

  • 리테일 및 기업 고객을 위한 디지털 뱅킹 앱과 포털
  • 코어 뱅킹 시스템을 교체하지 않고 API로 감싸 확장하는 서비스
  • 지급 파일, 승인, 거래 명세서, 현금 포지션을 위한 기업 채널
  • 운영, 결제 조사, 고객 서비스를 위한 백오피스 도구
  • 이슬람 금융 기술과 코어 원장 확장

대표적인 통합

  • API, 메시지 대기열, 배치 인터페이스를 통한 코어 뱅킹 시스템

우리가 구축하는 것

  • 각 거래를 적합한 게이트웨이, 매입사, 결제 인프라로 라우팅하는 결제 오케스트레이션
  • 가맹점 온보딩, 포털, 보고
  • 정산, 수수료 계산, 지급 서비스
  • 거래, 정산, 은행 거래 명세서를 매칭하는 대사

우리가 구축하는 것

  • 대출 실행: 신청, 서류 수집, 의사결정 워크플로
  • 여신 팀이 검토할 수 있는 설명 가능한 모델과 규칙 기반 신용 의사결정
  • 대출 관리: 상환 일정, 상환, 연체, 추심
  • 브로커 및 파트너 포털

대표적인 통합

  • 신용평가사, 오픈 뱅킹 계좌 데이터, 신원 검증
  • 코어 뱅킹 또는 대출 원장, 자동이체나 카드로 처리하는 상환금 수납

우리가 구축하는 것

  • 포트폴리오, 거래, 문서를 제공하는 고객 포털과 앱
  • 수탁 기관 및 시장 데이터로 구축한 포트폴리오 및 고객 보고
  • 적합성 및 위험 성향 설문을 포함한 온보딩
  • 고객 검토, 제안, 리밸런싱을 위한 어드바이저 도구

대표적인 통합

  • 수탁 기관, 브로커, 시장 데이터 제공업체
  • 포트폴리오 관리 및 CRM 시스템

우리가 구축하는 것

  • 고객 및 브로커를 위한 견적·가입 여정
  • 상품, 배서, 갱신을 위한 증권 관리 확장
  • 문서 AI, 분류, 상태 추적을 갖춘 청구 접수
  • 가격 책정 및 위험 데이터 파이프라인

대표적인 통합

  • 증권 관리 및 청구 시스템
  • 보험료 수납, 환불, 총계정원장

우리가 구축하는 것

  • 충전, 이체, 청구서 납부, 가맹점 결제를 지원하는 지갑 앱
  • 복식 전기와 일일 잔액 검증을 갖춘 지갑 원장
  • 모바일 결제를 위한 카드 발급 및 토큰화 카드
  • 운영 팀이 직접 변경할 수 있는 한도, 수수료, 로열티 규칙

대표적인 통합

  • 카드 발급 프로세서 및 토큰화 서비스

우리가 구축하는 것

  • 금융 시뮬레이션을 위한 대형 정량 모델(LQM)
  • 고빈도 매매(HFT) 시스템
  • 실시간 사기, AML, 행동 이상 탐지

대표적인 통합

  • 시장 데이터 제공업체 및 거래소

구축하고 연결하고 보호하는 것

  • 디지털 채널

    고객을 위해 설계하고 월급날과 월말의 부하를 견디도록 구축한 웹·모바일 뱅킹, 지갑, 투자 앱.

  • 코어 확장

    위험한 교체 없이 상품과 채널을 추가하는, 코어 뱅킹 또는 원장 시스템 주변의 서비스.

  • 결제 오케스트레이션

    게이트웨이, 매입사, 결제 인프라 전반에서 라우팅, 재시도, 장애 조치를 수행하고 모든 시도를 기록합니다.

  • 온보딩과 KYC

    신원 확인, 심사, 문서 캡처와 사람 검토로 이어지는 명확한 경로를 갖춘 개인 및 기업 온보딩.

  • 사기 및 거래 모니터링

    거래가 발생하는 즉시 점수를 매기고 의심스러운 거래를 검토를 위해 보류하는 규칙과 머신러닝 모델.

  • 대사와 재무

    원장, 프로세서, 은행, ERP 전반을 매칭하여 재무 팀이 신뢰하는 데이터로 마감하도록 합니다.

  • 은행 연결

    호스트 간 채널, EBICS, 은행 API를 통한 ISO 20022 및 MT 형식의 결제와 거래 명세서.

  • 카드 처리

    ISO 8583 또는 API를 통한 매입사, 프로세서, 발급 플랫폼. 매장에는 EMV 단말기, 온라인에는 3-D Secure를 적용합니다.

  • 오픈 뱅킹

    규제 대상 은행 API와 애그리게이터를 통해 계좌 정보를 조회하고 결제를 개시하며, 동의는 적절히 처리합니다.

  • 신원, KYC, AML

    신원 검증, 제재 및 정치적 주요 인물 심사, 부정적 언론 보도 확인. 모든 결과를 감사를 위해 보관합니다.

  • ERP 및 총계정원장

    전기, 수수료, 정산을 ERP로 가져와 재무 팀이 운영 팀과 같은 수치를 보도록 합니다.

  • 카드 데이터와 PCI DSS

    토큰화와 호스팅 결제 필드를 통해 카드 데이터를 가능한 한 귀사 시스템 밖에 두도록 설계하여 PCI DSS 범위를 줄입니다. 카드 데이터를 반드시 처리해야 하는 경우에는 평가자가 테스트할 통제 항목에 맞춰 구축합니다.

  • 강력한 고객 인증

    2단계 인증과 거래 서명처럼 결제 및 은행 규정이 요구하는 인증 흐름을 구축하며, 귀사 위험 팀이 허용하는 예외만 적용합니다.

  • KYC 및 AML 통제

    온보딩과 모니터링은 컴플라이언스 팀이 필요로 하는 증거를 남깁니다. 무엇을, 언제, 어느 제공업체가 확인했고 누가 결정했는지입니다.

  • 데이터 보호

    작업 시작 전에 개인 및 금융 데이터를 저장·처리할 수 있는 위치를 합의하고, 해당되는 경우 GDPR과 UAE PDPL, 사우디 PDPL 같은 현지 법률에 맞춰 설계합니다.

  • 감사 추적과 복원력

    자금, 한도, 권한에 대한 모든 변경을 기록하고 추적할 수 있게 하며, 운영 복원력 규정이 기대하는 대로 안전하게 실패하고 복구하도록 시스템을 구축합니다.

업무 방식

  1. 준비도 검토

    프린시펄 엔지니어가 범위, 시스템, 데이터, 규제 요구사항을 검토합니다.

  2. 연결 설계

    통합 계층, 실패 경로, 감사 추적을 가장 먼저 설계합니다.

  3. 수행 및 운영

    수용 게이트 뒤의 단계적 릴리스, 그 다음 합의된 서비스 수준에 따른 관리형 운영.

디지털 금융 상품의 전체 구조뱅킹 또는 지갑 앱은 하나의 API 계층과 통신합니다. 그 뒤에는 신원 확인, 카드 처리, 코어 원장이 있습니다. 거래는 발생하는 즉시 심사되고, 의심스러운 항목은 사람의 검토를 위해 보류됩니다.사용자고객서비스뱅킹 또는 지갑 앱웹 및 모바일XSISAPI 계층인증, 한도, 감사 로그서드파티KYC 및 AML 제공업체온보딩 및 심사게이트웨이카드 프로세서발급 및 승인은행코어 뱅킹 또는 원장계좌, 잔액, 전기서비스사기 및 거래 모니터링규칙 및 모델사용자컴플라이언스 및 운영 팀보류 및 이관 건 검토12REST/JSON · OAuth 2.03REST/JSONwebhook4REST/JSON · ISO 200225REST/JSON6ISO 8583789

디지털 금융 상품의 전체 구조

뱅킹 또는 지갑 앱은 하나의 API 계층과 통신합니다. 그 뒤에는 신원 확인, 카드 처리, 코어 원장이 있습니다. 거래는 발생하는 즉시 심사되고, 의심스러운 항목은 사람의 검토를 위해 보류됩니다.

  • 기본 흐름
  • 비동기
  • 예외 경로
9단계로 된 흐름

단계별 흐름

  1. 고객에서 뱅킹 또는 지갑 앱로: 가입, 결제, 이체 (기본 흐름).
  2. 뱅킹 또는 지갑 앱에서 API 계층로: 요청, REST/JSON · OAuth 2.0 사용 (기본 흐름).
  3. API 계층에서 KYC 및 AML 제공업체로: 신원 및 심사 확인, REST/JSON · webhook 사용 (기본 흐름).
  4. API 계층에서 코어 뱅킹 또는 원장로: 전기 및 잔액, REST/JSON · ISO 20022 사용 (기본 흐름).
  5. API 계층에서 카드 프로세서로: 카드 발급 및 통제, REST/JSON 사용 (기본 흐름).
  6. 카드 프로세서에서 코어 뱅킹 또는 원장로: 카드 거래, ISO 8583 사용 (비동기).
  7. API 계층에서 사기 및 거래 모니터링로: 이벤트 스트림으로 전달되는 심사 대상 거래 (비동기).
  8. 사기 및 거래 모니터링에서 컴플라이언스 및 운영 팀로: 검토를 위해 보류됨 (예외 경로).
  9. KYC 및 AML 제공업체에서 컴플라이언스 및 운영 팀로: 실패하거나 불명확한 확인 건 이관 (예외 경로).
ERP에서 은행으로: 결제는 나가고, 거래 명세서는 들어옵니다승인된 결제는 서명된 ISO 20022 파일로 호스트 간 채널을 통해 ERP를 떠납니다. 상태 보고서와 거래 명세서도 같은 경로로 돌아와 미결 항목과 대사됩니다. 거절된 결제와 미매칭 항목은 사유와 함께 귀사 팀에 전달됩니다.ERPERP결제 배치, 미결 항목, 총계정원장XSIS통합 계층매핑, 검증, 서명, 스케줄링게이트웨이보안 은행 채널호스트 간 SFTP, EBICS,은행 API은행은행결제 및 자금 관리서비스대사 엔진매칭 규칙과 허용 오차사용자자금 관리 및 재무 팀거절 및 불일치 검토1REST/JSON · IDoc2ISO 20022 pain.001OpenPGP3SFTP H2H4pain.002 · camt.053MT9405SFTP H2H6camt.0537REST/JSON8pain.002 RJCT910

ERP에서 은행으로: 결제는 나가고, 거래 명세서는 들어옵니다

승인된 결제는 서명된 ISO 20022 파일로 호스트 간 채널을 통해 ERP를 떠납니다. 상태 보고서와 거래 명세서도 같은 경로로 돌아와 미결 항목과 대사됩니다. 거절된 결제와 미매칭 항목은 사유와 함께 귀사 팀에 전달됩니다.

  • 기본 흐름
  • 비동기
  • 예외 경로
10단계로 된 흐름

단계별 흐름

  1. ERP에서 통합 계층로: 승인된 결제 배치, REST/JSON · IDoc 사용 (기본 흐름).
  2. 통합 계층에서 보안 은행 채널로: 서명 및 암호화된 지급 파일, ISO 20022 pain.001 · OpenPGP 사용 (기본 흐름).
  3. 보안 은행 채널에서 은행로: 은행으로 전송됨, SFTP H2H 사용 (기본 흐름).
  4. 은행에서 보안 은행 채널로: 상태 보고서 및 거래 명세서, pain.002 · camt.053 · MT940 사용 (비동기).
  5. 보안 은행 채널에서 통합 계층로: 수집 및 검증됨, SFTP H2H 사용 (비동기).
  6. 통합 계층에서 대사 엔진로: 거래 명세서 항목, camt.053 사용 (비동기).
  7. 대사 엔진에서 ERP로: 매칭된 전기 처리, REST/JSON 사용 (기본 흐름).
  8. 통합 계층에서 자금 관리 및 재무 팀로: 거절된 결제, 사유 코드 포함, pain.002 RJCT 사용 (예외 경로).
  9. 대사 엔진에서 자금 관리 및 재무 팀로: 미매칭 항목: 대사 불일치 (예외 경로).
  10. 자금 관리 및 재무 팀에서 ERP로: 수정 후 재제출 (예외 경로).
카드 결제: 포스에서 승인하고, 나중에 정산하고, ERP에서 대사합니다단말기나 결제 화면이 게이트웨이에 요청하고, 게이트웨이가 매입사에 요청하며, 매입사가 카드 스킴과 발급사로 라우팅합니다. 정산 파일은 나중에 도착해 ERP에서 매출 및 수수료와 대사됩니다. 시간 초과 시 자동 취소가 발생하여 고객이 이중 청구되지 않습니다.POSEMV 단말기 또는 온라인 결제칩, 비접촉, 이커머스게이트웨이결제 게이트웨이토큰화 및 라우팅은행매입사승인 및 정산서드파티카드 스킴 및 발급사승인 또는 거절ERPERP매출, 수수료, 지급금XSIS통합 계층정산 파일 파싱 및 매칭사용자결제 운영 팀불일치, 분쟁, 지불 거절1EMV · REST/JSON2ISO 85833ISO 85834ISO 85835SFTP6REST/JSON7ISO 8583 04008

카드 결제: 포스에서 승인하고, 나중에 정산하고, ERP에서 대사합니다

단말기나 결제 화면이 게이트웨이에 요청하고, 게이트웨이가 매입사에 요청하며, 매입사가 카드 스킴과 발급사로 라우팅합니다. 정산 파일은 나중에 도착해 ERP에서 매출 및 수수료와 대사됩니다. 시간 초과 시 자동 취소가 발생하여 고객이 이중 청구되지 않습니다.

  • 기본 흐름
  • 비동기
  • 예외 경로
8단계로 된 흐름

단계별 흐름

  1. EMV 단말기 또는 온라인 결제에서 결제 게이트웨이로: 승인 요청, EMV · REST/JSON 사용 (기본 흐름).
  2. 결제 게이트웨이에서 매입사로: 승인, ISO 8583 사용 (기본 흐름).
  3. 매입사에서 카드 스킴 및 발급사로: 발급사로 라우팅됨, ISO 8583 사용 (기본 흐름).
  4. 매입사에서 결제 게이트웨이로: 승인 또는 거절, ISO 8583 사용 (비동기).
  5. 매입사에서 통합 계층로: 정산 및 수수료 파일, SFTP 사용 (비동기).
  6. 통합 계층에서 ERP로: 정산된 매출, 수수료, 지급금, REST/JSON 사용 (기본 흐름).
  7. 결제 게이트웨이에서 EMV 단말기 또는 온라인 결제로: 시간 내 응답 없음: 자동 취소, ISO 8583 0400 사용 (예외 경로).
  8. 통합 계층에서 결제 운영 팀로: 정산 불일치 또는 지불 거절 (예외 경로).
오픈 뱅킹: 고객 동의 기반의 데이터와 결제고객이 동의하면 커넥터가 토큰을 보관하고, 은행에 대한 모든 호출이 승인되고 기록됩니다. 동의가 만료되거나 철회되면 앱이 조용히 실패하지 않고 고객에게 다시 요청합니다.사용자고객서비스귀사 앱 또는 플랫폼자금 관리, 대출, 회계XSIS오픈 뱅킹 커넥터동의, 토큰, 데이터 정규화은행은행 API 또는 애그리게이터계좌 정보 조회 및 결제 개시ERPERP 또는 원장현금 포지션 및 대사12REST/JSON3OAuth 2.0 · FAPI · REST4REST/JSON · webhook5REST/JSON6HTTP 401 · 4037

오픈 뱅킹: 고객 동의 기반의 데이터와 결제

고객이 동의하면 커넥터가 토큰을 보관하고, 은행에 대한 모든 호출이 승인되고 기록됩니다. 동의가 만료되거나 철회되면 앱이 조용히 실패하지 않고 고객에게 다시 요청합니다.

  • 기본 흐름
  • 비동기
  • 예외 경로
7단계로 된 흐름

단계별 흐름

  1. 고객에서 귀사 앱 또는 플랫폼로: 동의 부여 (기본 흐름).
  2. 귀사 앱 또는 플랫폼에서 오픈 뱅킹 커넥터로: 계좌 및 결제 요청, REST/JSON 사용 (기본 흐름).
  3. 오픈 뱅킹 커넥터에서 은행 API 또는 애그리게이터로: 승인된 API 호출, OAuth 2.0 · FAPI · REST 사용 (기본 흐름).
  4. 은행 API 또는 애그리게이터에서 오픈 뱅킹 커넥터로: 잔액, 거래, 결제 상태, REST/JSON · webhook 사용 (비동기).
  5. 오픈 뱅킹 커넥터에서 ERP 또는 원장로: 정규화된 거래, REST/JSON 사용 (기본 흐름).
  6. 은행 API 또는 애그리게이터에서 오픈 뱅킹 커넥터로: 동의 만료 또는 철회, HTTP 401 · 403 사용 (예외 경로).
  7. 오픈 뱅킹 커넥터에서 귀사 앱 또는 플랫폼로: 고객에게 동의 갱신 요청 (예외 경로).

시작 방법

다음 단계

  1. 일정 협의

    팀이 이메일로 연락해 세션 시간을 협의합니다.

  2. 사전 컨설팅 세션

    무료 30분 온라인 사전 컨설팅 세션에서 목표, 시스템, 제약 조건을 함께 검토합니다.

  3. 준비도 검토

    무료 48시간 준비도 검토에서 프린시펄 아키텍트가 프로젝트를 6개 항목의 준비 완료 정의에 비추어 점검하고 적합한 트랙을 권고합니다.

  4. 트랙 선택

    범위가 준비된 프로젝트는 영업일 기준 3~5일 이내 구속력 있는 제안서를 받습니다. 개념 단계 프로젝트는 블루프린트 스튜디오에서 시작합니다. 장애가 있거나 문서화되지 않았거나 통합이 필요한 운영 시스템은 1~2주 진단으로 시작합니다. 블루프린트 스튜디오와 진단은 각각 고정 비용이며 제안서에 명시됩니다.

가장 빠른 시작은 신속 협업 패키지 중 하나인 의무 전자 인보이스 및 ERP 준비도 스프린트 패키지입니다.

시작 지점

질문과 답변

XSIS는 어떤 핀테크 업무를 수행합니까?

핀테크는 우리의 핵심 산업입니다. 디지털 뱅킹 및 지갑 앱, 결제·정산 서비스, 대출 플랫폼, 자산 보고, 보험 여정을 구축하고 은행, 카드 프로세서, KYC 제공업체, ERP 시스템과 연결합니다. 고객사 이름은 동의 없이 공개하지 않으므로, 우리가 다루는 시스템과 표준, 그리고 귀사 아키텍트와의 기술 논의를 통해 경험을 보여드립니다.

귀사의 규제 및 보안 요구사항 안에서 일할 수 있습니까?

네. 귀사의 정책 안에서 일합니다. 귀사의 접근 규칙, 환경, 변경 프로세스, 감사 요구사항이 그 대상입니다. 작업 시작 전에 데이터 처리 방식, 엔지니어가 접근할 수 있는 환경, 위험 및 컴플라이언스 팀이 필요로 하는 증거를 합의합니다. 우리가 적용하는 통제를 명확히 설명하여 평가자가 검토할 수 있게 합니다.

코어 뱅킹 시스템을 교체해야 합니까?

대개는 아닙니다. 대부분의 은행은 코어를 잘 정의된 API로 감싸고 새 상품과 채널을 그 주변의 서비스로 구축할 때 더 많은 이점을 얻습니다. 이렇게 하면 고객 대면 부분은 더 빠르게 바뀌면서 기준 시스템은 안정적으로 유지됩니다. 코어를 반드시 교체해야 하는 경우에는 구 시스템을 끌 때까지 두 시스템을 대사하며 단계적으로 마이그레이션합니다.

카드 데이터는 어떻게 처리합니까?

최대한 적은 시스템만 전체 카드 번호를 보도록 설계합니다. 호스팅 결제 필드, 토큰화, 네트워크 토큰을 통해 카드 데이터를 프로세서에 두어 PCI DSS 범위를 줄입니다. 시스템이 카드 데이터를 반드시 처리해야 하는 경우에는 적용되는 PCI DSS 통제에 맞춰 구축하고 평가자를 위해 문서화합니다.

ISO 20022와 즉시 결제를 지원할 수 있습니까?

네. 기업 결제와 보고를 위한 ISO 20022 메시지(pain.001, camt.053 등), 그리고 즉시 결제 및 고액 결제 시스템이 사용하는 은행 간 메시지를 생성·검증·판독하는 서비스를 구축합니다. 스킴과 은행마다 규칙이 다르므로 각 기관의 구현 가이드를 따르고 그 테스트 환경에서 검증합니다.

사기 및 거래 모니터링을 구축할 수 있습니까?

네. 분석가가 읽고 변경할 수 있는 규칙과 귀사 데이터로 학습한 머신러닝 모델을 결합하고, 각 경보가 발생한 이유를 설명합니다. 경보는 분석가가 판단하는 케이스 대기열로 전달되며, 그 판단은 다시 규칙과 모델에 반영됩니다. 이미 전문 심사 제공업체를 사용 중이라면 연결해 드립니다.

핀테크 프로젝트의 비용을 결정하는 요인은 무엇입니까?

관련된 시스템과 파트너의 수, 적용되는 규제 통제, 시스템이 처리해야 하는 거래량과 속도, 그리고 오픈 전에 파트너가 요구하는 테스트의 양입니다. 은행이나 프로세서 인증 같은 파트너 온보딩이 코드보다 일정을 좌우하는 경우가 많습니다. 디스커버리 후에 추정하며, 작업을 단계로 나누어 하나씩 예산을 배정하고 승인할 수 있게 합니다.

계약이 아니라 대화로 시작하십시오.

구축하거나 연결하거나 보호할 대상을 알려 주십시오. 아키텍트가 함께 검토한 뒤 시작 지점을 제안합니다.