Wuji는 은행, 금융, 인터넷 금융 산업에 인터넷 기반 금융 위험 관리 기술의 핵심으로 공급망 금융을 기반으로 한 금융 기술 출력에 전념하고 있습니다. 인터넷 신용의 핵심 시스템 구축, Spark[Spark ML, Spark Streaming(Flink 대체), Spark Graphx] 기술 시스템을 기반으로 한 신용 리스크 관리 시스템 구축, 효과적인 저금리 제공을 위한 장기 Flow 사업을 다룹니다. - 파트너에 대한 위험 자산. 은행에서 인터넷 금융회사, 기술수출 금융기술회사로의 여정을 경험한 후, 저자는 산업과 시스템 설계에 대한 자신의 이해를 공유하고자 한다.
본 글은 *** 3개 부분으로 나누어져 있다(외국은행의 외환거래시스템 리스크 구축, 인터넷 금융 개인 리스크 관리 시스템 구축, 공급망 금융 중소기업 리스크 관리 시스템) 건설)
이 부분에서는 외환 거래 시스템의 위험 통제에 대한 비즈니스 측면에 대해 자세히 소개합니다. 실제로 기술 혁신은 없으며 제3자 공급업체의 시스템이 많이 사용됩니다. 은행에 많은 편의를 제공한 IBM MQ, Webmethod 및 Oracle에 감사드립니다. 이 은행에서는 Tomcat, Jetty, Spring Cloud, Dubbo 또는 ZooKeeper를 볼 수 없습니다. Yarn과 Hadoop의 관계. 기술적인 관점에서 보면 간단합니다. 구입할 수 있으면 만들지 않을 것입니다. 특히 ITIL은 DevOps를 안내하는 데 사용되며 Jenkins는 CI 및 CD라고 하며(실행할 수 있는 심각한 자동화 테스트 케이스를 본 적이 없습니다.) 배치를 실행하는 시스템은 거의 모든 종류의 저장 프로시저입니다(말해야 할 것은 , 은행은 거래 정보가 많고 데이터 흐름도 많습니다. 또한 과거에는 데이터 플랫폼 구축이 완벽하지 않았습니다. 이러한 일괄 프로세스는 비즈니스 유형에 지나지 않습니다. 통계처리, 계좌보충, 추심 및 지급, 이자계산, 결제 등의 업무는 은행의 핵심업무인 예금 및 대출, 자본자산관리, 자산관리 및 카드사업, 중개업무 등을 담당합니다. 하루가 끝나든 낮에든 완료됨) 여기서 JVM 튜닝은 하드웨어 구매에 의존합니다(저자가 17년 전에 일했던 회사의 CEO는 "우리 소프트웨어가 좋지도 않고, 돈도 있고, 하드웨어도 보충할 수 있는데... (하오하오)) 게다가 제가 가장 불편한 건 SVN을 쓰는 거고, Git이 아무리 작아도 뭔지 모르겠어요. , 나는 JHipster를 결코 시도하지 않을 것입니다. 저자는 한때 Nodejs를 기반으로 작은 도구를 만들었지만, js도 프로덕션 환경의 도구로 사용할 수 있다며 다른 그룹의 사람들로부터 오랫동안 비웃음을 받았습니다... 그런데 Quants를 만드는 사람들은 Haskell을 사용하고 있습니다. 계산 엔진을 패키징하고 일부 DSL 실습을 통해 제가 배운 내용을 여러분과 공유할 기회가 있습니다. 이곳에서 3년 반 동안 나는 말도 안되는 소리를 하는 법을 배웠고, 잘하지 못하는 원리를 더 많이 알게 되었습니다.
2012년 말, 아주 유명한 외국계 은행에 입사하여 시스템 구축 업무를 맡을 기회가 있었습니다. 당시 주요 업무는 Murex2000에서 Murex3.1로의 업그레이드 프로젝트를 완료하는 것이었습니다. 논의는 1년 이상 걸렸고, 최종 결과물은 해외 각급 고위 지도자들의 승인과 더불어 TOM 문서의 작성이었습니다. (TOM: Target Of Model)은 본 프로젝트의 궁극적인 목표로, 기존 비즈니스에 대한 영향과 기존 시스템의 전환을 의미합니다.
솔직히 말해서, 이 프로젝트를 통해 외국 은행의 시스템이 왜 그렇게 거대하고 복잡한지 알 수 있었습니다. 물론 KYC, GAAC, 세탁 방지 및 은행의 규제 특성을 준수하는 것 외에도 많은 시스템이 은행에서 볼 수 있습니다. 인터넷 관점은 엄청난 인력 낭비(한 프로젝트에 2명의 프로그램 관리자, 4-5명의 프로젝트 관리자, 많은 BA, 물론 쓸모없는 기술 BA가 많은 이유)와 결합되어 극도로 중복됩니다. 위치, 그들은 실제로 건축가가 아니며 기껏해야 일부 시스템 구성, 프로세스 변경 및 수직 현장 비즈니스를 알고 있습니다. 실제로 작업을 수행하는 소수는 모두 중국인입니다. 왜 그들은 종종 대규모 그룹을 보냅니다. 사람들이 출장을 위해 싱가포르로 갑니다. 모든 온라인 거래자들은 런던으로 갑니다. 결국 많은 거래자들이 영국에 있기 때문에 이는 의미가 있습니다. 전체 시스템 구축에는 처음에는 시스템 마이그레이션, 데이터 마이그레이션, 다양한 UAT, UVT, Rollout 등을 포함하여 4~5년이 걸릴 것으로 예상됩니다. 프로젝트 자체로 돌아가면, Murex는 외환 거래 관리 시스템 Vendor 중 절대적인 리더라고 할 수 있습니다. 회사는 유명하고, 시스템이 크고, 주문량이 많고, Consultant가 큰 평판을 얻고 있습니다. 자본관리나 외환거래 관리를 해본 사람이라면 Summit/Murex/Calypso 세 회사를 아실 겁니다. 솔직히 기술적인 측면에서 적당한 중간 플랫폼을 선택한다면 저는 Calypso를 선택하겠습니다. 프레임워크) 지원되는 제품(옵션, 바닐라, 파생 상품, 담보 및 Fx 등) 관점이나 기능 관점에서 크고 포괄적인 제품을 선택하는 경우: MSL(Murex 스크립트 언어) 가능, 다양한 Pre -거래, 거래 후 설정, 가격, 곡선 손익, 전략 수립, 다양한 VaR 계산, 거래 기록, 현금, PV, NPV 조회 및 서류 확인, 전자와 관계없이 백그라운드로 작동할 수도 있습니다. 확인(Swift) 정산, 감사, 금융, 화해 등 온갖 일에는 비싸지만 Murex만 선택하겠습니다.
그때부터 외환시스템을 기반으로 한 리스크 시스템 구축에 대해 더 많이 접하게 되었기 때문에 제가 접촉한 은행들의 외환거래 시스템의 리스크 관리에 대해 간략하게 말씀드리겠습니다. 한 가지 공통점은 모든 기업이 위험을 회피한다는 것입니다. 일반적으로 위험에 대한 내성이 낮습니다. 리스크 관점에서 볼 때 은행은 다음 사항에만 중점을 둡니다.
a) 유동성 리스크 이는 저자가 많은 ALM 프로젝트 구축에 참여하고 은행의 대차대조표와 유동성에 많은 관심을 기울였기 때문일 수 있습니다. 저는 유동성 리스크를 가장 먼저 언급합니다. 한 문장으로 말하면 우리는 주식을 통제하고 흐름을 조정하며 부채의 안정성과 자산의 높은 유동성을 유지하려고 노력함으로써 유동성 리스크를 다룹니다. 저자는 한때 상위 10개 상호 금융 P2P 회사에서 기술 관리자로 일했습니다. 그런데 P2P가 자본 풀과 불일치를 완전히 취소한 후에는 유동성이 생존 여부의 열쇠가 됩니다. 자본 시장에서 자금 조달 능력은 또 다른 문제이지만 자금 조달이 운전 자본인 경우 환매를 위해 자금을 세탁할 수 있는 다른 채널만 찾을 수 있습니다.
불일치와 관련하여 소위 차입은 장기입니다. 부채의 대부분이 단기 정기 예금이나 요구불 예금이지만 자산의 대부분은 중장기 예금이기 때문입니다. 잠깐, 이것들은 모두 장부상 사업이고, 보증, 약정, 은행 인수 어음, 자산 관리 상품과 같은 부외 사업도 많이 있습니다. 유동성에 영향을 미칩니다. 외환거래도 마찬가지다. 근본원인은 돈이 있느냐다.
b) 신용 위험: 거래상대방 위험 또는 성과 위험은 거래상대방이 정당한 의무를 이행하지 않을 위험을 의미합니다. 장내파생상품거래와 장외파생상품거래는 결제방법이 다르기 때문에 신용위험도 다릅니다.
c). 운영 위험: Murex가 OSP를 제공하는 이유는 가장 잘 이해됩니다.
d) 시장 위험: "시장 위험" 링크보다 더 나은 설명은 없습니다. , 환율리스크, 금리리스크, 원자재 등을 모두 포함합니다. Market Risk에 대해서 이야기하자면, VaR(Value At Risk)에 대해 이야기해 보겠습니다. 시스템을 설계할 때 실제로 많은 계산이 고려됩니다. 모두 PnL, PPL 등이 필요합니다. 솔직히 말해서 Map-Reduce 아이디어는 개선될 수 있습니다. MongoDB에 10년 이상의 데이터를 로드한 다음 자체 Map을 실험해 보았습니다. -Reduce 기능은 결국 단일 스레드 JS 기능이므로 효율성 향상이 매우 작습니다.
외환 거래 위험에는 세 가지 원인이 있습니다.
1) 경제 주체는 서로 다른 통화의 교환 또는 전환으로 인해 자체적으로 외환 포지션을 보유합니다.
p>
2) 환율의 불확실한 요인
3) 환율 변동으로 인해 경제 주체에 경제적 손실이 발생할 가능성을 잘 생각해보면 바로 이 둘 때문이다. 통화 차원과 시간 차원에서는 위험이 존재하며 변수는 국가마다 환율 체계가 다르다는 것입니다. 변동성의 하한선이 달라 변동하기 쉽다), 통화정책(기본적으로 결정적인 역할을 함), 환율은 구매력과 이자율 동등성 이론에 따라 물가상승률과 이자율에 따라 결정됨 두 나라), 회계제도(계정구분, 회계방법의 선택, 회계차이, 금전적/비금전적 방법은 무엇이고 유동/비유동적 방법은 무엇인지, 시간측정방법 등도 있음) 회계 시스템 얘기를 하다가 문득 아래 사진이 생각났네요. 하하. 물론 국제수지, 국내 정치상황 등도 있습니다.
이는 기본적으로 고려되는 위험요소들이며, 외환거래시스템 전반의 설계에 있어서 가장 중요한 것은 계산입니다. 예를 들어 위에서 언급한 VaR의 계산은 다음과 같은 결과로 계산됩니다.
전체 시스템의 아키텍처 설계는 기능면에서 어렵지 않습니다. 특히 이러한 외자 은행의 경우 가장 복잡한 외부 비즈니스 도킹이 은행에 많이 있습니다. 시스템을 설계할 때 이것이 기사의 시작 부분에서도 언급된 이유입니다. 많은 인터넷 기반 기술은 위험 측면 외에도 더 나은 방법을 위해 시스템의 외부 도킹이 실제로 문제입니다. 시스템을 외부 비즈니스 시스템과 연결하고, 당시 프로토콜 변환을 위한 프로젝트도 있었고, 양 당사자 모두 XML을 사용하여 데이터 교환을 위한 자체 형식, 특히 MxML을 사용한 변환 작업을 정의하는 데 많은 참여를 했습니다. 제가 처음에 IBM에 감사를 표하는 이유이기도 합니다. 마지막으로 외환거래시스템이 어떤 모습인지 모두가 이해할 수 있도록 전체적인 기능도를 알려드리겠습니다.
비즈니스 기능으로 따지면 프론트오피스, 미들오피스, 백오피스에 지나지 않습니다. Murex가 외환 거래 관리 플랫폼이라고 불리는 이유는 우리가 직접 거래 시스템을 만들지 않기 때문입니다. 일반적으로 거래 시스템은 외부 소스에서 구매하거나 자체적으로 개발하므로 그다지 복잡하지 않습니다. 특히 실제 외환거래의 경우 대상상품은 대부분 Fx Spot, Fx Forward, Fx Swap(파생상품 제외)이며, 가상거래는 마진관리를 추가하는 것에 지나지 않습니다. 실제로
프런트 엔드 관리 기능은 거래 입력, 실시간 시장 상황, 포지션, 손익, 거래 전 분석, 전략 시행 계산, 시나리오 분석, 시뮬레이션, 고객 관리, 외부 원격 거래 관리 등;
미들 오피스: 신용 관리, 시장 한도(익스포저, 손절매 관리, VaR, 기간 한도, 컴플라이언스 관리), 각종 계산(VaR, 자본 적정성, 스트레스 테스트, 백 테스트);
백엔드: 워크플로 구성, 다양한 일일 작업 제어, 보고서, 메시지 관리, 담보, 회계 관리(거래 포지션 평가, 외환 포지션 계산, 보고서, 다중 지원 필수) 엔터티, 다중 통화, 모든 자산에 대한 다중 회계 시스템 계산).
시스템의 모든 기능은 비즈니스 지원에서 비롯됩니다. 제 멘토인 Des Greer는 10여년 전에 은행에 각각 자체 임무를 수행하는 많은 시스템이 있다고 말했습니다. 복잡성은 시스템이 속한 비즈니스 라인 자체가 복잡하지 않습니다. 산업용 소프트웨어를 설계하는 것은 최소한의 비용으로 가장 기본적인 기능을 완성하기 위해 높은 응집력과 낮은 결합도를 가져야 합니다. 아이디어. 물론 완전히 정확하지는 않을 수도 있지만 의미가 있습니다. 새해 첫날, 너무 많은 글을 장황하게 썼는데, 독자들에게 너무 모호한 내용이 아니길 바랍니다. 다음 두 부분에서는 비즈니스 내용을 줄이고 기술 관련 내용을 더 많이 작성하려고 노력할 것입니다.
모두 새해 복 많이 받으세요 - 레온 2019-2-5