금융자산 담보·신용보강 효과 점검 — 담보가 줄여 준 노출과 장부 충당금이 맞는지 한 화면에서 확인하는 IFRS 7 신용위험 공시 점검

도입 포인트 — 이 앱을 사용해야 하는 이유

신용위험 공시에서 담보와 그 밖의 신용보강은 “노출을 얼마나 줄였는가” 를 보여 주는 자료입니다. 그런데 현업의 담보 관리 자료, 고객 미결 항목, 손실충당금 계정은 서로 다른 곳에 있어서, 담보가 줄여 준 금액과 장부 충당금이 서로 어울리는지는 결산 때마다 사람이 손으로 대조합니다. 이 앱은 그 대조를 한 화면에 올려 점검할 노출을 먼저 걸러 주고, 합계가 맞는지를 매번 다시 맞춥니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 샘플 64건

검증용 샘플 기준 연월 202412 의 노출 64건은 총장부금액 1,512.86억 원이고 담보 완화액은 919.86억 원, 완화율은 60.80% 입니다. 담보 후 순노출은 593.00억 원이 남습니다. 상품 유형으로 나누면 예금·금융상품 담보대출은 99.37%, 신용보험 가입 매출채권은 81.50%, 부동산담보대출은 74.01%, 보증서 담보대출은 70.22%, 무담보 신용대출은 0% 입니다.

신용위험 단계로 나누면 1단계 54.79% · 2단계 91.57% · 3단계 44.07% 로, 3단계(신용손상) 노출 8건은 총장부금액 200.69억 원 가운데 112.24억 원이 담보로 보전되지 않은 채 남고 장부 충당금은 33.08억 원입니다. 이 숫자가 충분한지에 대한 판단은 이 화면이 하지 않습니다. 대신 충당금 부족 후보(C03) 4건, 전액 보전인데 충당금이 큰 노출(C02) 4건처럼 ‘확인해 볼 노출’ 을 골라 줍니다. 샘플은 가상의 거래처로 만든 것이라 숫자 자체에 의미를 두지 않습니다.

이런 회사에 맞습니다

담보부 대출이나 보증, 신용보험이 걸린 채권이 있고 결산 때 신용위험 공시 자료를 만드는 재무팀, 그리고 담보 관리 부서와 회계 부서의 숫자를 서로 대조해야 하는 회사입니다. 담보가 거의 없는 회사에는 효과가 크지 않습니다. 반대로 담보 건수가 많을수록 “어느 노출부터 볼까” 를 정하는 데 드는 시간이 줄어듭니다.

실행 화면

실제로 돌아가는 화면 6종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리인지를 아래에 적었습니다. 숫자는 모두 같은 샘플에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

조회와 요약

조회조건은 기준 연월(필수)과 상품 유형 · 신용위험 단계 · 담보 평가일 · 점검 코드 · 점검 결과(선택)입니다. 조회 버튼은 조건 입력란 오른쪽 끝에 있고 Enter 키로도 조회합니다.

처음 열면 기준 연월(기본 202412)로 자동 조회합니다. 요약 8개를 먼저 읽는 이유는 담보가 노출 전체를 어느 정도 줄였는지 가늠한 다음 개별 노출로 내려가는 편이 순서가 맞기 때문입니다.

점검 필요는 ‘틀렸다’ 가 아니라 ‘원인을 확인해 보라’ 는 표시입니다. 코드를 보면 무엇을 확인할지(재평가 일정, 선순위 설정, 충당금 근거)가 바로 갈립니다.

묶음별로 보기

노출 명세 다음 탭이 상품 유형별, 단계별 완화 효과입니다. 두 탭의 합계는 노출 명세 합계와 같아야 하며 그 등식을 대사 결과에서 확인합니다.

무담보 대출은 완화액이 0 이라 순노출이 총장부금액과 같습니다. 묶음별로 점검 필요 건수와 판정이 함께 나오므로 어느 상품에서 확인할 노출이 몰리는지 한눈에 봅니다.

신용손상 노출은 담보로 얼마나 보전되고 남은 부분에 충당금이 얼마나 쌓였는지가 핵심 질문이라 순노출 대비 충당금률(29.48%)을 따로 둡니다. 기준서가 정한 비율이 아니라 확인용 지표입니다.

한 건 열어 보기와 대사

한 노출의 조정 후 담보 가치가 0 으로 나오는 이유(선순위 설정액이 할인 후 평가액 이상)가 이 창에서 바로 보입니다. 점검 코드의 사유를 숫자로 확인하는 자리입니다.

두 종류를 섞지 않는 것이 이 화면의 약속입니다. 합계가 맞는지(정합성)와 장부가 점검 기준에 걸리는지(장부 점검)는 서로 다른 질문이라 표를 나눠 둡니다.

점검 코드 판정 규칙

노출마다 아래 규칙 가운데 위에서부터 먼저 걸리는 하나를 적용합니다. 수치 기준은 화면 점검용 가정이며 기준서가 정한 값이 아닙니다.

산출 순서

조정 후 가치 = max(0, 평가액 × (1 − 할인율 ÷ 100) − 선순위 설정액), 담보 완화액 = min(총장부금액, Σ 조정 후 가치), 담보 후 순노출 = 총장부금액 − 담보 완화액입니다. 초과 담보 = max(0, 조정 후 담보 가치 − 총장부금액) 는 완화액에서 빼고 별도 컬럼에 보입니다. 완화율은 담보 완화액 ÷ 총장부금액 × 100 이며 노출 · 상품 유형 · 단계마다 같은 식을 씁니다.

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 이어 주지 못하는 자리만 붙이는 쪽으로 만들었습니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

표준으로 되는 것과 안 되는 것

기준서와의 연결

다음 표는 이 화면이 어떤 공시 요구사항과 연결되는지를 정리한 것입니다. 기준서의 조문 번호는 적지 않았고, 연결 방식과 최종 판단 주체를 함께 적었습니다.

도입할 때 정해야 하는 것

코딩보다 합의가 먼저입니다. 합의 없이 화면부터 올리면 첫 회의에서 “이 숫자는 어디 기준이냐” 로 막힙니다.

CDS 구성

이 사례의 화면은 샘플 노출 128건을 OData 서비스에서 읽어 보여 줍니다. 운영 데이터에서는 담보 라인 조정과 노출별 완화액 계산을 CDS 로 내려 화면은 결과를 읽기만 하도록 만드는 것이 맞습니다. 아래는 그때 만드는 뷰의 스케치입니다.

표준 CDS 뷰 이름과 필드는 시스템 버전에 따라 다를 수 있어 도입 시 확인이 필요합니다. 담보 원천 뷰는 회사의 담보 관리 데이터에 맞춰 정해야 하며 확인 필요입니다.

원천 테이블과 필드 매핑

① 담보 라인 조정 후 가치

라인마다 할인율과 선순위 설정액을 반영합니다. 값이 음수가 되지 않도록 0 으로 막는 것이 중요합니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '담보 라인 조정 후 가치'
define view entity ZI_ColLineValue
  as select from ZI_CollateralLine as ln
{
  key ln.ExposureId,
  key ln.LineNo,
      ln.CollateralType,
      ln.EvaluationDate,
      ln.AppraisedAmount,
      ln.HaircutPercent,
      ln.PriorLienAmount,
      // 조정 후 가치 = max(0, 평가액 × (1 − 할인율 ÷ 100) − 선순위 설정액)
      case when ( ln.AppraisedAmount * ( 100 - ln.HaircutPercent ) / 100 ) - ln.PriorLienAmount > 0
           then ( ln.AppraisedAmount * ( 100 - ln.HaircutPercent ) / 100 ) - ln.PriorLienAmount
           else 0 end as AdjustedValue
}

② 노출별 완화액

노출 한 건의 라인 가치를 더한 뒤 총장부금액을 한도로 완화액을 구합니다. 한도를 넘는 부분은 초과 담보로 따로 둡니다. 한도 적용 방식은 회사 정책에 따라 달라질 수 있습니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '노출별 담보 완화액'
define view entity ZI_ExposureMitigation
  as select from ZI_ExposureItem as ex
  association [0..*] to ZI_ColLineValue as _Line
    on _Line.ExposureId = ex.ExposureId
{
  key ex.ExposureId,
      ex.GrossAmount,
      sum( _Line.AdjustedValue ) as CollateralNet,
      // 담보 완화액 = min(총장부금액, 조정 후 담보 가치)
      least( ex.GrossAmount, sum( _Line.AdjustedValue ) ) as MitigatedAmount
}
group by ex.ExposureId, ex.GrossAmount

③ 점검 코드 판정

노출 단위 규칙을 위에서부터 평가해 먼저 걸리는 하나를 남깁니다. 기준값 2% · 50% · 12개월은 점검용 가정이므로 파라미터 테이블로 빼 두는 편이 안전합니다.

@EndUserText.label: '노출 점검 코드'
define view entity ZI_ExposureCheck
  as select from ZI_ExposureMitigation as m
{
  key m.ExposureId,
      m.GrossAmount,
      m.CollateralNet,
      m.MitigatedAmount,
      m.GrossAmount - m.MitigatedAmount as NetExposure,
      case
        when m.CollateralCount > 0 and m.CollateralNet = 0           then 'C04'
        when m.Stage = '3' and m.NetExposure > 0
             and m.AllowanceAmount < m.NetExposure * 0.5            then 'C03'
        when m.CollateralNet >= m.GrossAmount
             and m.AllowanceAmount > m.GrossAmount * 0.02           then 'C02'
        when m.OldestEvaluation < $session.system_date               then 'C01'  // 기준일 − 12개월 비교는 환경에 맞게 확인 필요
        else 'I00'
      end as CheckCode
}

운영에서 달라지는 것

샘플은 파일을 읽는 서비스로 동작하지만 운영에서는 같은 엔티티셋을 CDS 기반 OData 서비스가 내줍니다. 화면은 서비스 주소만 바꾸면 되고, 날짜 조건과 정렬은 서비스가 처리합니다. 서비스에 붙지 못하면 화면이 “서비스 연결 안내” 를 띄웁니다.

자주 묻는 질문

도입 상담에서 자주 받는 질문들입니다. 다섯 묶음으로 나누어 적었습니다.

숫자와 산식

점검 코드와 판단

데이터와 연동

대사와 검증

도입과 운영