트랜잭션 인텔리전스 시스템 구축: MT950 은행 명세서에서 자동 대조(Automated Reconciliation)까지

구축 이유

대부분의 AI 데모는 챗봇(Chatbots), 코파일럿(Copilots), 또는 AI 에이전트(AI Agents)에 집중합니다.

하지만 기업 내부에서 가장 큰 자동화 기회 중 하나는 훨씬 덜 화려합니다:

재무 대조 (Financial reconciliation).

매일 재무 팀은 은행 명세서로부터 수천 건의 트랜잭션(Transactions)을 받습니다.

트랜잭션은 다음과 같이 보일 수 있습니다:

PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157

인간 회계사에게 그 의미는 명확합니다.

하지만 기계에게 그것은 그저 텍스트일 뿐입니다.

과제는 트랜잭션 내러티브(Transaction narratives)를 구조화된 비즈니스 지식으로 변환하는 것입니다.

이 글에서는 가공되지 않은 MT950 은행 명세서를 송장(Invoices), 계약서(Contracts), 고객 기록(Customer records)과 자동으로 대조할 수 있는 기계 판독 가능 엔티티(Machine-readable entities)로 변환하는 트랜잭션 인텔리전스 시스템(Transaction Intelligence System)을 어떻게 구축했는지 설명합니다.

실제 문제

많은 사람이 결제 게이트웨이(Payment gateways)가 대조 문제를 해결한다고 가정합니다.

그렇지 않습니다.

결제 게이트웨이는 결제 수집(Payment collection)을 해결합니다.

기업의 대조(Enterprise reconciliation)는 다음과 같은 서로 다른 질문에 답해야 합니다:

• 어떤 고객이 결제를 했는가?
• 어떤 송장(Invoice)이 결제되고 있는가?
• 어떤 계약(Contract)이 해당 트랜잭션을 규정하는가?
• 이것은 부분 결제(Partial payment)인가?
• 결제 금액이 정확한가?

그러한 답변은 결제 자체에는 존재하지 않습니다.

그것들은 비즈니스 컨텍스트(Business context) 안에 존재합니다.

시스템 아키텍처 (System Architecture)

아키텍처는 여러 계층으로 구성됩니다:

MT950 Statement
       ↓
Canonical Transformation
...

각 계층은 특정 문제를 해결합니다.

1단계: 합성 기업 데이터셋 생성 (Synthetic Enterprise Dataset Generation)

가장 큰 과제 중 하나는 학습 데이터(Training data)를 확보하는 것이었습니다.

실제 기업의 재무 데이터는 일반적으로 개인정보 보호 제한으로 인해 사용할 수 없습니다.

대신, 저는 다음과 같은 내용을 포함하는 합성 데이터셋(Synthetic datasets)을 생성했습니다:

고객 마스터 (Customer Master)

{
  "customer_id": "CUS-00002",
  "legal_name": "ALPHABRIDGE SOLUTIONS"
...

계약 마스터 (Contract Master)

{
  "contract_id": "CNT-2024-587",
  "customer_id": "CUS-00002"
...

송장 마스터 (Invoice Master)

{
  "invoice_number": "MFG-INV-000157",
  "contract_id": "CNT-2024-587"
...

MT950 명세서 (MT950 Statements)

PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157

이는 훈련 및 평가를 위한 완전한 정답(ground-truth) 환경을 구축했습니다.

2단계: 정형 변환 (Canonical Transformation)

가공되지 않은 (Raw) MT950 파일은 다루기가 어렵습니다.

하나의 트랜잭션(transaction):

:61:240226C3979,85NTRFNONREF
:86:PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157

은 다음과 같은 정형 구조(canonical structure)로 변환됩니다:

{
  "transaction_id": "...",
  "currency": "EUR",
...

이것이 후속 프로세싱을 위한 표준화된 입력값이 됩니다.

3단계: 분류 체계 설계 (Taxonomy Design)

모델을 훈련시키기 전에 무엇이 중요한지를 정의해야 합니다.

분류 체계(taxonomy)에는 다음이 포함됩니다:

COMPANY
INVOICE
CONTRACT
...

예시:

PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157

은 다음과 같이 변환됩니다:

{
  "COMPANY": "ALPHABRIDGE SOLUTIONS",
  "INVOICE": "MFG-INV-000157",
...

이 분류 체계는 시스템의 언어가 됩니다.

4단계: 자동 사전 레이블링 (Automated Prelabeling)

수동 어노테이션(manual annotation)은 확장성이 떨어집니다.

대신, 저는 다음을 사용하여 사전 레이블링 엔진을 구축했습니다:

• 정규 표현식 (Regular expressions)
• 마스터 데이터 조회 (Master data lookups)
• 휴리스틱 규칙 (Heuristic rules)

예시:

invoice_pattern = r"[A-Z]{3}-INV-\d+"

이는 사람이 검토하기 전에 초기 어노테이션을 자동으로 생성합니다.

결과:

• 더 빠른 어노테이션
• 더 높은 일관성
• 레이블링 비용 감소

5단계: Doccano 어노테이션 (Doccano Annotation)

사전 레이블링된 데이터는 Doccano로 임포트됩니다.

사람 검토자가 다음 항목을 검증합니다:

• 회사명 (Company names)
• 송장 참조 (Invoice references)
• 계약 식별자 (Contract identifiers)
• 구매 주문 (Purchase orders)
• 결제 유형 (Payment types)

이를 통해 모델 훈련에 필요한 정답(ground truth)이 생성됩니다.

6단계: 금융 NER 모델 미세 조정 (Fine-Tuning a Financial NER Model)

훈련 파이프라인:

Doccano
    ↓
BIO 변환 (BIO Conversion)
...

대상 엔티티 (Target entities):

COMPANY
INVOICE
CONTRACT
...

목표는 일반적인 NER이 아닙니다.

목표는 기업 트랜잭션 이해 (enterprise transaction understanding)입니다.

7단계: 엔티티 해소 (Entity Resolution)

엔티티 추출(entity extraction)만으로는 충분하지 않습니다.

예를 들어:

ALPHABRIDGE

다음으로 해결되어야 합니다:

{
  "customer_id": "CUS-00002",
  "legal_name": "ALPHABRIDGE SOLUTIONS"
...

해결 엔진(resolution engine)은 다음을 사용합니다:

정확한 일치 (Exact Matching)

ALPHABRIDGE SOLUTIONS

별칭 일치 (Alias Matching)

ALPHABRIDGE LTD

퍼지 일치 (Fuzzy Matching)

ALPHA BRIDGE

임베딩 유사도 (Embedding Similarity)

더 까다로운 사례를 위한 방법입니다.

8단계: 대조 엔진 (Reconciliation Engine)

엔티티가 해결되면:

{
  "customer_id": "CUS-00002",
  "invoice_number": "MFG-INV-000157"
...

대조 엔진(reconciliation engine)은 다음 사항을 검증합니다:

• 고객 소유권 (Customer ownership)
• 계약 관계 (Contract relationships)
• 송장 존재 여부 (Invoice existence)
• 금액 일관성 (Amount consistency)

가능한 결과값:

AUTO_RECONCILED
PARTIAL_MATCH
OVERPAYMENT
...

9단계: API 레이어 (API Layer)

최종 시스템은 다음과 같은 엔드포인트(endpoints)를 노출합니다:

POST /reconcile/text

입력(Input):

{
  "narrative": "PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157"
}

출력(Output):

{
  "customer_id": "CUS-00002",
  "invoice_number": "MFG-INV-000157",
...

이를 통해 다음 시스템들과 통합할 수 있습니다:

• ERP 시스템 (ERP systems)
• 회계 플랫폼 (Accounting platforms)
• 재무 운영 워크플로 (Finance operations workflows)
• AI 에이전트 (AI agents)

교훈 (Lessons Learned)

모델을 구축하는 것이 가장 어려운 부분은 아니었습니다.

가장 어려웠던 부분은 다음과 같습니다:

데이터 품질 (Data Quality)

저품질 데이터는 저품질 자동화를 생성합니다.

분류 체계 설계 (Taxonomy Design)

모델은 당신이 정의한 개념만을 이해합니다.

표준 데이터 (Canonical Data)

표준 구조(canonical structures)가 없으면, 다운스트림(downstream) 자동화는 취약해집니다.

엔티티 해결 (Entity Resolution)

해결(resolution) 과정이 없는 추출(extraction)은 비즈니스 가치가 제한적입니다.

마치며 (Final Thoughts)

대부분의 엔터프라이즈 자동화 프로젝트는 AI 모델에 집중합니다.

제 경험상, 진짜 도전 과제는 비즈니스에 대한 이해입니다.

가장 중요한 아키텍처는 다음과 같습니다:

Raw Data
↓
Canonical Data
...

AI는 스택(stack)의 한 계층일 뿐입니다.

엔터프라이즈 AI로 성공하는 조직은 자율 에이전트(autonomous agents)에 투자하기 전에 데이터 기반(data foundations), 비즈니스 분류 체계(business taxonomies), 그리고 트랜잭션 인텔리전스(transaction intelligence)에 먼저 투자하는 조직이 될 것입니다.

기업 운영을 위한 AI를 구축하고 있다면, 자동화(automation)에 앞서 이해(understanding)부터 시작하십시오.