MongoDB 및 BIAN을 사용한 코어 뱅킹 현대화

MongoDB 제품: MongoDB Atlas, MongoDB 집계 파이프라인, Change Streams

솔루션 개요

코어 뱅킹은 은행을 실행하는 엔진입니다. 고객, 계좌, 잔고, 결제 및 금융 이벤트를 관리하며 모든 하위 채널, 제품 및 보고 시스템이 여기에 종속됩니다.

이러한 중심성 때문에 코어를 현대화하기가 어려운 것입니다. 여전히 많은 은행이 분편화된 데이터, 고정된 스키마, 배치 창 및 점대점 통합에 의지하고 있습니다. 새로운 제품, 채널 및 규제 요구사항이 등장함에 따라 복잡성이 증가하는 경우가 많습니다.

솔루션은 무엇일까요? BIAN(Banking Industry Architecture Network)과 MongoDB를 사용하여 코어 뱅킹을 현대화합니다.

BIAN 은 비즈니스 아키텍처를 정의합니다. MongoDB 는 이를 구성 가능하고 이벤트 기반이며 도메인이 소유한 데이터 플랫폼으로 구현합니다.

BIAN: 타겟 아키텍처

BIAN(Banking Industry Architecture Network)은 역량을 서비스 도메인으로 모델링하는 은행 산업 표준인 BIAN 프레임워크를 정의합니다.

은행 작업을 서비스 도메인으로 정의하면 각 팀에게 작업을 수행할 수 있는 작업 범위가 명확하게 정해지므로 다음과 같은 결과가 나오게 됩니다.

더 명확한 경계 컨텍스트: 각 서비스 도메인에는 정의된 범위와 목적이 있습니다.
명확한 데이터 소유권: 하나의 도메인이 각 비즈니스 객체와 데이터를 소유합니다.
더 명확한 API 경계: 도메인은 공유 데이터베이스 액세스 대신 표준 계약을 통해 상호 작용합니다.
의미적 표류 감소: 공유 어휘는 팀 및 시스템 전체에서 터미 일관성을 유지합니다.

MongoDB: 구현 데이터 플랫폼

MongoDB는 BIAN 서비스 도메인 모델을 실제로 구현합니다. 각 은행 필요사항은 네이티브 MongoDB 기능에 매핑됩니다.

document model은 고객, 계좌 및 중청 KYC 기록과 같은 계층적 뱅킹 데이터에 적합합니다.
다중 문서 ACID 트랜잭션은 단일 커밋에서 동기 환전을 실행합니다.
변경 스트림은 폴링 없이 실시간으로 재무 이벤트를 전파합니다.
스키마 유효성 검사기와 집계 파이프라인은 데이터에 가까운 곳에서 회계 규칙을 시행합니다.

이 솔루션은 배송 파이프라인을 방해하지 않고 중요 은행 업무를 점진적으로 현대화하는 방법을 보여줍니다.

참조 아키텍처

이 솔루션은 세 개의 FastAPI 백엔드 서비스로 구성되어 있습니다. 각 서비스는 전체 금융 흐름에서 고유한 책임을 가집니다.

계정 서비스 는 고객 및 계정 상태를 소유합니다. 이는 주체 참조 데이터 및 현재 계정 기능에 대한 BIAN 정렬 작업을 노출합니다.
트랜잭션 서비스 는 결제 시작 및 결제 실행을 소유합니다. 하나의 MongoDB ACID transaction으로 운영 결제 결과를 동기적으로 쓰기 (write)합니다.
원장 서비스 는 회계 파이프라인을 소유합니다. 실행된 트랜잭션에 비동기적으로 반응하고 부원장 및 저널 게시에 필요한 재무 측 기록을 도출합니다.

이 분리는 아키텍처의 중심입니다. 결제 실행, 계정 상태 및 회계 진실은 서로 관련되어 있지만 동일한 관심사항은 아닙니다. 이 디자인은 각 서비스가 고유한 범위 내에서 진화할 수 있도록 하면서 데이터 계보를 통해 서로 연결되도록 유지합니다.

그림 1. 고수준 아키텍처: BIAN 및 MongoDB를 사용한 코어 뱅킹.

클릭하여 확대

채널은 애플리케이션 및 서비스 경계를 통해 입력됩니다.

사용자는 웹 UI를 통해 솔루션과 상호 작용합니다. 프론트엔드는 채널 계층 역할을 하고 경로 기반 라우팅을 통해 요청을 관련 백엔드 서비스로 보냅니다. 서비스는 BIAN 스타일 엔드포인트를 노출하므로 인터페이스 계층은 데이터베이스 구조가 노출되지 않고 비즈니스 역량에 정렬되어 있습니다.
계정 서비스는 고객 및 계정 사실을 소유합니다.

계정 서비스는 customers 및 accounts 컬렉션을 읽고 쓰기 (write)를 수행합니다. 고객 마스터 데이터, KYC 관련 계정 컨텍스트, 잔고 및 계정 라이프사이클 작업의 실제 소스이자 역할을 합니다. 이는 계정 및 잔고 검색을 위한 동기 읽기 경로입니다.
트랜잭션 서비스는 결제를 동기적으로 실행합니다.

결제가 시작되면 트랜잭션 서비스는 하나의 MongoDB 다중 문서 ACID transaction으로 처리합니다. 이 솔루션에서는 작업 단위가 소스 계정 잔액에서 차감하고, 대상 계정 잔액에 크레딧을 적용하고, 트랜잭션 기록을 삽입하고, 결제 상태를 업데이트하고, 관련 알림 또는 상태 변경 사항을 하나의 커밋에 쓰기 (write)를 합니다.

운영 계정 잔액은 트랜잭션 흐름에서 즉시 업데이트되는 반면, 원장 흐름은 총계정원장을 비동기적으로 업데이트합니다. 총계정원장은 게시 창이 끝나면 배치로 별도 게시됩니다.
MongoDB는 회계 전파를 위한 이벤트 소스가 됩니다.

원장 경로는 변경사항을 폴링하지 않으며 솔루션의 외부 메시지 버스에 의지하지 않습니다. 대신 원장 서비스는 MongoDB 변경 스트림을 통해 transactions 컬렉션을 모니터링합니다. 새로 삽입된 모든 트랜잭션은 비동기 계산 처리의 trigger가 됩니다.

이는 운영 실행과 재무 처리 간의 건축적 핸드오프입니다.

그림 2. 레저 서비스.
클릭하여 확대
원장 서비스의 1 단계에서 회계 경계 객체를 쓰기 (write)합니다.

첫 번째 저너 작업자는 트랜잭션 변경 스트림을 사용하여 각 결제마다 하나의 ledgerEvent 문서를 쓰기 (write)합니다. 이 문서에는 차변 및 크레딧, 포스팅 컨텍스트를 포함하여 비즈니스 이벤트에 대한 회계 해석이 포함되어 있습니다. 이벤트를 쓰기 (write)하기 전에 작업자는 차변과 대변이 균형을 이루는지 확인합니다.

이 제어가 중요한 이유는 ledgerEvents 가 플로우에서 첫 번째 변경할 수 없는 회계 컬렉션이기 때문입니다. 여기에 작성된 데이터는 subLedgerEntries 및 journalEntries로 하단으로 전파되기 전에 정확해야 합니다.

건축적으로 ledgerEvents 은 결제 도메인과 재무 도메인 사이의 경계 컬렉션입니다. 원래 결제로 돌아가는 계보를 유지하면서 결제 속도와 회계 속도를 분리합니다.
원장 서비스의 2 단계는 개체 수준 회계 엔트리를 프로젝트합니다.

두 번째 원장 작업자는 ledgerEvents 을 모니터링하고 각 이벤트를 하나는 차변과 하나는 크레딧인 두 개의 subLedgerEntries에 프로젝트합니다. 이는 ACID transaction에서 이러한 엔트리를 함께 쓰기 (write)하고 이벤트가 균형을 이루고 두 GL 계정 모두 계정 차트에서 유효한 게시 리부인지 다시 확인합니다.

이 단계에서는 고객 성명서 및 일중 위치 보기에 사용되는 개체 수준 회계 진실이 생성됩니다.
원장 서비스의 3 단계에서 총계정을 게시합니다.

배치 워커는 대기 중인 부서비 기록을 주기적으로 조정하고 균형 journalEntries으로 말아서 넣습니다. 조정이 실패하면 게시 사이클은 건너략니다. 성공하면 워커는 저널 기록을 쓰기 (write)를 하고, 결과 저널 식별자를 소스 기록에 다시 스탬하고 게시 상태를 바꿉니다.

실시간 결제의 경우에도 총계정원은 배치로 게시됩니다. 총계정원이 아닌 부계정원이 일중 잔액의 정확한 소스입니다. 스키마는 건별 트랜잭션을 게시하는 기관을 위해 실시간 게시 모드를 지원하지만, 이 솔루션은 표준 산업 관행과 일관적인 배치 총계정원 게시를 사용합니다.
이 플랫폼은 양방향으로 최종까지 추적성을 유지하여 설계를 감사할 수 있게 합니다.

데이터 플로우는 양방향의 비즈니스 및 회계 계층에서 완전히 추적할 수 있습니다. 결제는 결제에서 트랜잭션으로 이동한 다음 ledgerEvents으로 이동한 다음 subLedgerEntries으로 이동한 다음 마지막으로 journalEntries로 이동합니다. 모든 저널 기입은 동일한 체인을 통해 추적하여 초기 결제로 돌아갈 수 있습니다. 이 양방향 계보는 하위 소비자에 대한 파이프라인 추적 UI, 감사 가능성 및 건축 명확성을 지원합니다.

데이터 모델 접근 방식

데이터 모델은 서비스와 동일한 건축 분리를 따릅니다. 각 컬렉션은 플로우에서 고유한 비즈니스 또는 회계 목적을 제공하기 때문에 존재합니다.

작업 컬렉션

customers 고객 마스터 기록과 중청된 KYC 컨텍스트를 저장합니다.
accounts 현재 계정 상태를 저장하고 잔액의 실질적인 소스 역할을 합니다.
payments PENDING 및 SETTLED 등의 지불 명령 및 라이프사이클 상태를 저장합니다.
transactions 지불 사실을 저장하고 원장 파이프라인의 이벤트 소스가 됩니다.

이러한 컬렉션은 아키텍처의 운영 측면을 지원합니다. 고객 및 계정 워크플로우를 직접 제공하며 계정 및 트랜잭션 서비스에 의해 동기적으로 업데이트됩니다.

회계 컬렉션

glAccounts 계정 차트를 저장하고 게시할 수 있는 내용을 검증합니다.
ledgerEvents 트랜잭션당 하나의 회계 경계 기록을 저장합니다.
subLedgerEntries 객체 수준의 차변 및 크레딧 게시물을 저장합니다.
journalEntries 균형 일반 총계정 엔트리를 저장합니다.

데이터 흐름

플로우는 신중하며 다음 단계는 컬렉션이 프로세스 플로우에 참여하는 방법을 요약합니다.

지불 지시가 지불에 도착합니다.
동기 결제 실행은 결과으로 실행된 트랜잭션 사실을 transactions 에 쓰기 (write)하고 작업 계정 잔액을 업데이트합니다.
트랜잭션에 대한 변경 스트림이 레저 파이프라인을 트리거합니다.

원장 수집 단계는 트랜잭션당 ledgerEvent 을 쓰기 (write)합니다.

원장 이벤트는 두 단계와 하위 경로를 결정하는 게시 모드를 모두 포함합니다.

샘플 문서: 원장 이벤트

{
  "eventId": "LE-20260415-000042",
  "idempotencyKey": "PAY-20260415-0042",
  "groupId": "GRP-20260415-000042",
  "eventType": "PAYMENT_PRINCIPAL",
  "debitLeg": {
    "glAccountCode": "1001",
    "controlAccountCode": "1000",
    "amount": {
      "$numberLong": "100000"
    },
    "currency": "USD",
    "entityReference": {
      "entityType": "ACCOUNT",
      "entityId": "ACC-001234"
    }
  },
  "creditLeg": {
    "glAccountCode": "2100",
    "controlAccountCode": "2000",
    "amount": {
      "$numberLong": "100000"
    },
    "currency": "USD",
    "entityReference": {
      "entityType": "ACCOUNT",
      "entityId": "ACC-001235"
    }
  },
  "postingMode": {
    "type": "BATCH"
  },
  "postingStatus": "PENDING",
  "sourceReference": {
    "sourceCollection": "transactions",
    "sourceId": "PAY-20260415-0042",
    "sourceSystem": "LEDGER_PIPELINE"
  }
}

프로젝션 단계는 이벤트당 2개의 subLedgerEntries 을 쓰기 (write) 위해 사용됩니다.

프로젝션 워커는 하나의 ledgerEvent 을 두 개의 subLedgerEntries로 팬아우하여 다리당 하나씩 ACID 트랜잭션으로 함께 쓰기합니다. 각각은 완전한 게시된 다리로 단독으로 존재하며, gl_batch 가 실제 ID를 스탬할 때까지 journalEntryId 는 "" 센티널을 유지합니다.

샘플 문서: 부속 입력

{
  "subLedgerId": "SLE-20260415-000042-D",
  "idempotencyKey": "LE-20260415-000042:DEBIT",
  "controlAccountCode": "1000",
  "side": "DEBIT",
  "amount": {
    "$numberLong": "100000"
  },
  "currency": "USD",
  "periodCode": "2026-04",
  "status": "POSTED",
  "journalEntryId": "",
  "entityReference": {
    "entityType": "ACCOUNT",
    "entityId": "ACC-001234"
  },
  "sourceReference": {
    "sourceCollection": "ledgerEvents",
    "sourceId": "LE-20260415-000042",
    "sourceSystem": "LEDGER_PIPELINE"
  }
}

대차 균형 크레딧 레그는 두 번째 문서입니다. 동일한 sourceId, 반대 side 및 controlAccountCode, entityId: ACC-001235. journalEntryId ($gt: "")의 부분 인덱스는 배치가 실제 저널 ID로 채워질 때까지 둘 다 제외합니다.

배치 경로는 대차 균형 journalEntries를 씁니다.

배치는 부서비 기록을 하나의 저널으로 집계하며, 그 균형 줄은 이베디된 배열에 있습니다.

샘플 문서: 저널 항목

{
  "journalId": "JNL-20260623-EOD-1001",
  "idempotencyKey": "BATCH-20260623-EOD:1000:2026-06",
  "periodCode": "2026-06",
  "journalType": "LEDGER_EVENT_POSTING",
  "status": "POSTED",
  "totalAmount": {
    "$numberLong": "1000000"
  },
  "entries": [
    {
      "lineNumber": 1,
      "accountCode": "1000",
      "side": "DEBIT",
      "amount": {
        "$numberLong": "1000000"
      },
      "currency": "USD"
    },
    {
      "lineNumber": 2,
      "accountCode": "2000",
      "side": "CREDIT",
      "amount": {
        "$numberLong": "1000000"
      },
      "currency": "USD"
    }
  ]
}

유효성 검사기는 회계 불변성을 시행합니다.

세 컬렉션 유효성 검사기는 회계 규칙을 데이터베이스에 푸시하므로 서비스 계층을 건너뛰는 쓰기 (write)는 여전히 장부를 손상할 수 없습니다. ledgerEvents 유효성 검사기는 비즈니스 필드를 필요로 하고 postingStatus 을 알려진 enum로 잠검니다.

_LEDGER_EVENTS_VALIDATOR = {"$jsonSchema": {
    "bsonType": "object",
    "required": ["eventId", "idempotencyKey", "groupId", "occurredAt", "valueDate", "eventType", "debitLeg", "creditLeg", "postingStatus", "sourceReference", "mappingVersion"],
    "properties": {
        "postingStatus": {"bsonType": "string", "enum":["PENDING", "POSTED", "FAILED"]},
        "debitLeg": _LEG_SCHEMA, "creditLeg": _LEG_SCHEMA,
    },
}}

subLedgerEntries 유효성 검사기는 side 을 DEBIT 또는 CREDIT 으로, status 를 POSTED 또는 FAILED으로 잠검고 모든 문서에 journalEntryId 이 필요하는데, "" 선테널은 gl_batch 이 실제 ID를 스탬할 때까지 이를 충족하므로 엔트리는 이 라이프사이클 밖에 있을 수 없습니다.

journalEntries 검증기는 Pacioli 균형 불변량을 직접 시행합니다. 즉, 차변 항목의 합계는 크레딧 항목의 합계와 같아야 하며, 모든 쓰기 (write) 시 $expr 로 확인합니다.

_JOURNAL_BALANCE_VALIDATOR = {"$expr": {"$eq": [
    {"$sum": {"$map": {"input": {"$filter": {"input": "$entries", "as": "e",
        "cond": {"$eq": ["$$e.side", "DEBIT"]}}}, "as": "e", "in": "$$e.amount"}}},
    {"$sum": {"$map": {"input": {"$filter": {"input": "$entries", "as": "e",
        "cond": {"$eq": ["$$e.side", "CREDIT"]}}}, "as": "e", "in": "$$e.amount"}}},
]}}

회계 컬렉션은 아키텍처의 재무 측면을 지원합니다. 이들은 운영 이벤트에서 파생되며, 계정 또는 트랜잭션 서비스에서 직접 작성되지 않습니다.

이 체인은 운영 속도와 회계 제어를 모두 제공합니다. 결제 실행은 전체 GL 게시를 기다리지 않지만 모든 결제는 여전히 감사 가능한 회계 경로로 해결됩니다.

MongoDB가 자연스럽게 적합한 이유는 무엇입니까?

고객 및 계정 데이터는 계층적이며 시간이 지남에 따라 변화합니다. 지불 기록에는 레일 및 채널별로 가변 메타데이터가 포함됩니다. 원장 기록은 관련된 회계 사실을 단일 비즈니스 문서로 그룹화합니다.

MongoDB에서는 서비스가 데이터를 생성하고 소비하는 방식과 일치하는 형태로 계정 상태, 라이프사이클 세부 정보, KYC 컨텍스트, 결제 사실 및 내장된 게시 행을 저장할 수 있습니다. 관계형 모델에서 필요한 반복되는 평면화 및 재조립을 피할 수 있습니다.

솔루션 빌드

이 섹션에서는 MongoDB를 사용하여 BIAN을 구현하는 방법과 Leafy Bank BIAN 솔루션을 복제하는 방법을 설명합니다. 전체 구현 가이드는 리포지토리를 복제하고 GitHub README의 설정 지침을 따르세요.

MongoDB로 BIAN 구현

대상 구현 범위를 정의합니다.

하나의 비즈니스 여정을 전체적으로 지원하는 연결된 서비스 도메인의 작은 세트로 시작합니다. 일반적인 은행의 초기 현대화 범위에는 온보딩 및 전체 현재 계좌 서비싱이 포함될 수도 있습니다. 이 솔루션의 범위는 실용적이고 족으며, 의도적으로 다음과 같이 줄여지니다.

주체 및 고객 참조 데이터
현재 계좌 상태 및 잔액
결제 시작 및 실행
재무 회계

BIAN 프레임워크는 구현 전에 소유 경계를 정의할 때 가장 유용하기 때문에 이것이 중요합니다.

비즈니스 실행과 회계 실행을 분리합니다.

결제 실행과 재무 개시를 별개의 관심사항으로 유지합니다. 먼저 결제를 운영 이벤트로 처리한 다음 실행된 트랜잭션 스트림에서 회계 기록을 비동기적으로 도출합니다.

이렇게 하면 결제와 회계가 각각의 속도로 실행될 수 있으며, 결제에서 저너 입력으로 및 그 반대 방향으로 회계 흐름을 완전히 감사할 수 있습니다.

서비스 도메인을 소유 컬렉션에 매핑합니다.

각 서비스가 콜렉션을 소유하고 공유 데이터베이스 액세스가 아닌 API를 통해 노출하도록 합니다.

계좌 는 고객 및 계좌 상태를 소유합니다.
트랜잭션 은 지불 시작 및 실행 기록을 가집니다.
원장 은 원장 이벤트, 부서비 기록, 저널 기록 등 재무 측 기록을 소유합니다.

필요한 경우 도메인 간 참조를 사용하세요. 하지만 쓰기 (write) 소유권을 공유하지 마세요.

계약 계층에서 BIAN 시맨틱스를 유지합니다.

BIAN에 정렬된 API 이름과 서비스 경계를 외부에 노출합니다. 내부적으로 개발자가 일반적이고 익숙한 필드 이름을 사용할 수 있도록 합니다. bianMappings 레지스트리에는 각 내부 필드를 BIAN 표준 이름에 연결하는 단일 정보 소스가 있습니다. 이를 통해 개발자가 지나치게 장황한 영구 모델을 사용하도록 강요하지 않고도 표준을 준수할 수 있습니다.

데이터 계층에서 회계 규칙을 시행합니다.

서비스 코드에서만 재무 무결성 검사를 실행하지 마십시오. MongoDB 트랜잭션, 검증기 및 인덱스를 사용하여 데이터에 가까운 이덴포턴시, 균형 게시 및 저널 불변성을 시행합니다.

이 BIAN + MongoDB 패턴은 리포지토리 자체를 복제하기 전에 필요한 컨텍스트입니다.

Leafy Bank BIAN 솔루션 복제

리포지토리를 복제하고 설정 지침을 따르세요.

GitHub 리포지토리 로 이동하여 README의 지침을 따라 다음을 수행하세요.

전제 조건 준비
리포지토리 복제하고 종속성 설치
MongoDB 데이터베이스 프로비저닝
백엔드 서비스 구성
프론트엔드 프록시 구성
원장 인덱스 및 유효성 검사기 만들기
샘플 데이터 시드
서비스 시작
전체 플로우 유효성 검사
파일로 제작된 경로 실행(필요한 경우)

참조 구현을 확장합니다.

기본 플로가 작동하면 아키텍처가 진화하도록 설계된 것과 동일한 방식으로 도메인별로 솔루션을 확장합니다. 기존 결제 및 원장 경로를 손상하지 않고 새로운 BIAN 정렬 서비스, 컬렉션 및 API를 추가합니다.

주요 학습 사항

이 솔루션 라이브러리에서 다음을 수행하는 방법을 배웃습니다.

BIAN 프레임워크를 사용하여 타겟 아키텍처 정의: 서비스 도메인은 더 명확한 비즈니스 경계, 데이터 소유권 및 API 계약을 생성합니다.
결제 실행과 장부 게시를 분리합니다: 아키텍처는 운영 상태를 동기적으로 업데이트하고 회계 상태를 비동기적으로 업데이트합니다.
두 플로우 모두에 MongoDB 사용: ACID 트랜잭션, 변경 스트림, 유효성 검사기 및 집계 파이프라인은 하나의 플랫폼에서 전체 패턴을 지원합니다.
ledgerEvents를 제어 경계로 처리: 데이터가 변경될 수 없는 재무 흐름에 들어가기 전에 균형 재무 항목을 검증합니다.
프로세스 플로우 중심으로 컬렉션 모델링: 각 컬렉션은 고유한 단계를 지원하고 아키텍처 전체에 걸쳐 계보를 보존해야 합니다.
점증적으로 현대화: 가치가 높은 도메인으로 시작하고 코어 전체를 교체하지 않고 플랫폼을 확장합니다.

작성자

Doina Brestoiu
Kiran Tulsulkar
Ainhoa Mugica
Andrea Alaman Calderon

돌아가기

AI 기반 인터랙티브 뱅킹

AML 네트워크 분석