핵심 은행, 클라우드, 아웃소싱 및 기술 규제

은행은 대장에 기록된 약속의 집합체입니다. 대장이 잘못되거나, 사용할 수 없거나, 위험에 노출되면 은행은 빚을 알지 못하고 고객에게 지불하거나 감독자에게 보고할 수 없습니다. 이러한 이유로 규제 당국은 현재 자본 계획만큼이나 기술 아키텍처, 아웃소싱 및 사이버 복원력을 철저히 조사하고 있습니다.

핵심 은행 시스템이 하는 일

핵심 은행 시스템은 기록의 대장입니다. 고객 및 계정 데이터를 보유하고, 모든 거래를 게시하고, 이자와 수수료를 계산하며, 다른 모든 것이 의존하는 잔액을 생성합니다.

일반적인 기능은 다음과 같습니다.

기능	무엇을 다룹니까?
고객 및 계정 관리	고객 기록, 계정 개설, 제품 약관, 계정 상태
대장 및 게시	실시간 또는 일괄 체크인의 청구 및 신용, 일반 대장 피드
예금	회계, 저축 및 기간 계좌, 이자 적립 및 자본화
대출	대출 발급 인터페이스, 일정, 환불, 미납, 프로비저닝 피드
결제 인터페이스	결제 허브, 카드 프로세서 및 대리인 계정 연결
제품 구성	코드 변경 없이 요금, 수수료, 한도 및 규칙
데이터 및 보고	재무, 위험, 규제 보고 및 AML 모니터링을 위한 추출

디지털 채널, 결제 허브, 카드 관리, 고객 온보딩 및 신원 확인, 제재 스크린, 거래 모니터링, 재무, 재정 및 규제 보고 엔진 등의 다른 시스템이 코어 주변에 있습니다.

아키텍처 선택

새로운 은행들은 보통 세 가지 모델 중에서 선택한다.

1. 은행 또는 공급업체가 호스팅하는 라이센스 소프트웨어. 은행은 구성 및 데이터를 제어하지만 통합 부담을 지게 됩니다.
2. 클라우드 플랫폼에서 소프트웨어를 서비스로 제공한다. 출시가 더 빠르지만, 은행은 벤더의 로드맵과 회복력에 의존하고 있으며, 이러한 배치는 아웃소싱이다.
3. 서비스로서 다른 면허를 가진 기관으로부터의 은행. 가장 빠른 경로, 그러나 새로운 은행이 자신의 충분한 물질을 가지고 있는지 여부에 대한 질문을 제기할 수 있습니다.

감독자는 모델을 규정하지 않으며, 은행이 선택한 모델을 이해하고 통제하는지를 평가한다.

아웃소싱 규칙

아웃소싱은 서비스 제공자가 은행이 스스로 수행 할 수있는 프로세스, 서비스 또는 활동을 수행하는 것을 의미합니다. In the EU, the EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02) entered into force on 30 September 2019. 이러한 지침은 EBA의 클라우드 서비스 제공업체에 대한 아웃소싱에 대한 별도의 권장 사항을 포함하여 이전의 지침을 대체했습니다.

중심 원칙은 책임을 아웃소싱할 수 없다는 것이다. 관리 기관은 아웃소싱된 모든 기능에 대해 책임을 지고 있다. 기관은 "항상 충분한 실체를 유지하고 '빈 껍질'이나 '우편함 엔티티'가되어서는 안된다."

중요한 기능

이 가이드라인은 아웃소싱 기능이 중요하거나 중요한 경우에 더욱 엄격한 요구 사항을 적용합니다. 즉, 실패가 규정 준수, 재무 성과 또는 지속성에 상당한 영향을 미칠 수 있습니다.

1. 계약하기 전에 공급자에 대한 위험 평가 및 실사를 수행.
2. 은행과 관할 당국에 대한 접근, 정보 및 감사의 계약상 권리를 포함합니다.
3. 통지 및 반대 또는 종료할 권리를 포함하여 서브 아웃소싱 제어.
4. 데이터 보안, 위치 및 기밀 유지 요구 사항을 설정합니다.
5. 탈출 전략을 문서화하고 시험했다.
6. 계획된 중요하거나 중요한 아웃소싱에 대해 관할 당국에 사전에 알려주십시오.

모든 배치는 은행에 의해 유지되는 아웃소싱 등록부에 기록되어야합니다.

EU 이외

이와 비슷한 규칙이 다른 지역에서도 적용된다. In the United Kingdom, PRA Supervisory Statement SS2/21 on outsourcing and third party risk management, published in March 2021 and effective from 31 March 2022, covers materiality, data security, cloud and exit planning. PRA는 "클라우드 및 기타 새로운 기술의 복원력과 채택을 강화"하기 위해 고안되었다고 설명한다.

In Singapore, the MAS Technology Risk Management Guidelines, published on 18 January 2021, set principles for technology risk governance, IT and cyber resilience, and are supplemented by a binding notice and incident reporting instructions.

DORA: 유럽연합의 디지털 운영 회복력

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. It brings ICT risk management, incident reporting, testing and third-party risk into one regulation for most EU financial entities, including banks.

도라 지역	은행에 대한 핵심 요구 사항
ICT 위험 관리	식별, 보호, 감지, 대응 및 복구를 포함하는 관리 기관에 의해 승인되고 감독되는 문서화된 프레임워크
사고 보고	주요 ICT 관련 사고는 제19조에 따라 조화된 분류 및 템플릿을 사용하여 관할 당국에 보고해야 합니다.
복원력 테스트	모든 단체를 위한 테스트 프로그램; for entities identified by authorities, advanced threat-led penetration testing at least every three years on live production systems under Article 26
ICT 제3자 위험	A strategy on ICT third-party risk, contractual minimums, and a register of information on all ICT service contracts under Article 28
중요 공급업체의 감독	The European Supervisory Authorities designate critical ICT third-party service providers and oversee them directly under Article 31

제28조는 ICT 서비스를 이용하는 금융기관은 DORA 및 금융서비스법에 의거하여 "항상 모든 의무의 준수와 이행에 대해 전적으로 책임을 진다"고 규정하고 있습니다. 등록부에는 중요한 기능을 지원하는 서비스를 구분해야 하며, 매년 새로운 조치를 보고하고 중요한 기능에 대한 계약계획을 적시에 당국에 통보해야 합니다.

DORA은 EBA 아웃소싱 가이드라인과 함께 적용된다. 실제로 은행들은 두 가지를 모두 만족시키는 하나의 재고를 유지한다.

사이버 보안

사이버 위험은 이제 신중한 감독의 일부가 되었습니다. 감독자들은 은행이 정보 자산을 파악하고 중요도에 비례하여 보호하며 공격을 신속하게 감지하고 정해진 허용 오차 내에서 중요 서비스를 복구할 것을 기대합니다.

주요 컨트롤은 일반적으로 다음을 포함합니다.

1. 다중 인증 및 특권 액세스 제어를 통해 강력한 ID 및 액세스 관리.
2. 벤더 릴리스를 포함한 안전한 소프트웨어 개발 및 변경 관리
3. 전송 중이거나 휴면 상태인 데이터의 암호화 및 은행이 제어하는 키 관리.
4. 지속적인 모니터링 및 사내 또는 아웃소싱 보안 운영 기능.
5. 취약점 관리 및 정기적인 침투 테스트.
6. 프로덕션 환경에서 분리되고 복원을 위해 테스트된 백업.
7. 규제 통지 및 고객 커뮤니케이션을 포함하는 사고 대응 계획.

수신자 확인, 행동 분석 및 강력한 고객 인증을 통해 지불이 즉각적이고 취소 불가능해지면서 고객을 보호할 수 있습니다.

규제 보고

은행들은 감독기관과 중앙은행에 대량의 데이터를 보고합니다. EU에서는 제430조 CRR 레버리지 비율, 대규모 노출, 유동성 요구 사항, 자산 부담 및 ESG 노출 등을 포함한 자기자본 요건에 대해 기관이 보고해야 하며 특정 기관은 재무 정보도 보고해야 합니다. 중앙은행은 통계 보고를 추가하고 금융 정보 단위는 의심스러운 거래 보고서를 받습니다.

보고서는 그 뒤에 있는 데이터만큼 좋습니다. 코어 시스템에서 레귤레이터까지의 체인은 일반적으로 다음과 같이 진행됩니다.

1. 핵심 시스템 및 기타 운영 시스템의 소스 데이터.
2. 데이터 웨어하우스 또는 보고 계층과 대표부 조정.
3. 데이터를 감독 템플릿 및 유효성 검사 규칙에 매핑하는 규제 보고 엔진.
4. 문서화된 제어 기능을 통해 재무 및 위험에 따라 검토하고 서명합니다.
5. 규제 기관의 포털 또는 형식을 통해 제출.

신규 은행들은 종종 출시 전에 제품 데이터를 보고서 템플릿에 매핑하는 작업을 과소 평가합니다.

감독관이 라이센스 신청서에서 무엇을 보는지

1. 각 시스템, 그 소유자, 공급자 및 위치에 대한 명확한 대상 아키텍처.
2. 중요하거나 중요한 기능 맵, 어떤 기능이 아웃소싱되고 누구에게 보여줍니다.
3. 시간과 비용이 현실적인 각 중요한 공급자에 대한 퇴출 계획
4. 감독 및 해결 기관을 포함한 데이터 위치 및 액세스.
5. 사업계획의 서비스 약속과 일치하는 복구 시간으로 테스트된 탄력성.
6. 준비성의 증거엔드투엔드 테스트, 마이그레이션 리허설 및 운영 수락 등.

그래서... ECB핀테크 은행 라이센싱에 대한 가이드 소비자에게 피해를 주거나 규제 기관의 개입을 요구하지 않고도 질서 있고 유동적인 방식으로 사업을 중단할 수 있는 탈퇴 계획을 고려하도록 요청합니다. 데이터를 검색할 수 있어야 하며, 계정을 이전할 수 있어야 하며, 지불을 순조롭게 중지할 수 있어야 합니다.

다음 기사에서는 코어 시스템이 연결되는 지불 레일에 대해 설명합니다: 카드 계획, SEPA, 인스턴트 지불 및 실시간 총 결제.