거래기록을 요청할 때는 ‘전체 내역’이라고만 쓰지 말고 주문·체결, 원화 입출금, 가상자산 입출금, 수수료, 잔액 snapshot을 기간과 market별로 나눈다. 화면 CSV로 부족하면 account ID, transaction hash, wallet address, network, 상태 변경 시각과 발급 기준 timezone을 포함한 자료를 서면 요청한다. 사업자 보관 의무와 이용자에게 제공되는 발급 범위는 같지 않을 수 있으므로 약관·개인정보 열람 절차와 사건별 법적 요구 절차를 구분한다.
목적에 따라 필요한 장부가 달라진다
세금 계산은 체결 수량·가격·수수료와 입출고 원가 연결이 필요하다. 무단 출금 분쟁은 login·인증 변경과 withdrawal address·tx hash가 중요하다. 상속은 기준일 잔액, account 소유와 신청인의 권한을 확인해야 한다. 한 종류 CSV가 세 목적을 모두 충족한다고 가정하지 않는다.
거래소 UI의 주문내역은 미체결·취소 주문을 포함할 수 있고 체결내역은 한 주문을 여러 fill로 나눈다. 주문 금액과 실제 체결 합계를 섞으면 수량과 수수료가 맞지 않는다. 원화 deposit·withdrawal과 blockchain transfer도 별도 ledger로 받아 연결한다.
거래기록 요청의 품질은 파일 수보다 기간·필드·기준시각이 목적에 맞게 정의됐는지에 달려 있다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 목적에 따라 필요한 장부가 달라진다
세금 계산은 체결 수량·가격·수수료와 입출고 원가 연결이 필요하다.
- 요청 범위를 표로 명시한다
시작·종료 시각과 timezone, account 식별자, market, asset을 적고 주문·fill·deposit·withdrawal·fee·adjustment를 각각 요청한다.
- 법정 보관과 고객 발급을 같은 권리로 단정하지 않는다
특정금융정보법은 가상자산사업자의 고객별 거래내역 분리 관리와 자금세탁방지 보고 체계를 둔다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
요청 범위를 표로 명시한다
시작·종료 시각과 timezone, account 식별자, market, asset을 적고 주문·fill·deposit·withdrawal·fee·adjustment를 각각 요청한다. UTC와 KST가 섞이면 날짜 경계의 거래가 누락되므로 export 설정과 field 설명을 함께 받는다. status code가 숫자라면 의미를 정의한 문서도 보존한다.
가상자산 출금에는 request ID와 onchain tx hash, network, destination address·memo, 신청·승인·broadcast·complete 시각이 필요할 수 있다. 입금에는 source hash, credited amount와 credit 시각을 본다. 내부이체는 public chain hash가 없을 수 있어 거래소 내부 reference를 요청한다.
| 자료 | 필수 필드 | 주요 용도 |
|---|---|---|
| 주문 | order ID·type·상태 | 취소·미체결 확인 |
| 체결 | fill ID·가격·수량·fee | 세금·정산 |
| 원화 | 은행·금액·처리시각 | 입출금 대조 |
| 가상자산 | network·address·tx hash | onchain 추적 |
| 잔액 | 기준시각·asset·locked | 상속·분쟁 |
법정 보관과 고객 발급을 같은 권리로 단정하지 않는다
특정금융정보법은 가상자산사업자의 고객별 거래내역 분리 관리와 자금세탁방지 보고 체계를 둔다. 법령·세무 규정에 따라 사업자가 보관하거나 관계기관에 제출하는 자료가 있어도 이용자가 원하는 가공 형식으로 즉시 받을 권리와 동일하지는 않다. 해당 자료의 목적·제공 근거가 다르기 때문이다.
가상자산 이용자 보호법은 수탁 가상자산에 대해 이용자명부를 작성·비치하고 종류·수량·가상자산주소를 기록하도록 한다. 이는 어떤 기본 항목이 관리되는지 보여 주지만 모든 내부 보안 log가 일반 고객 발급 대상이라는 의미는 아니다. 구체 발급은 약관·개인정보 열람·소송상 문서제출 등 경로를 확인한다.
셀프 export 뒤 누락을 검산한다
웹·앱에서 CSV를 내려받으면 행 수, 최소·최대 시각, asset별 합계와 화면 총계를 확인한다. 페이지 제한이나 최대 조회 기간 때문에 여러 파일로 나뉘면 경계 시각이 중복·누락되지 않는지 본다. Excel이 긴 order ID를 지수 표기하거나 앞자리 0을 없애지 않도록 원본 CSV를 직접 보존한다.
체결 수량 합계와 order executed volume, fee currency를 검산하고 withdrawal은 explorer receipt와 대조한다. adjustment·airdrop·staking reward·delisting conversion 같은 비거래 변동도 별도 category로 요청한다. balance 변화가 설명되지 않으면 차액과 직전·직후 시각을 표시해 문의한다.
- 요청 목적·기간·timezone을 명시한다
- 주문과 개별 fill을 각각 받는다
- 입출금 request ID와 onchain hash를 연결한다
- 원본 CSV를 수정 없이 보존하고 SHA-256을 기록한다
- 누락 행·필드 질문과 고객센터 답변을 보관한다
개인정보 열람 요청은 대상 정보를 특정한다
본인 account의 개인정보와 이용 기록을 열람하려면 사업자 개인정보 처리방침의 열람 청구 부서·본인확인 방법을 따른다. ‘내 모든 데이터’보다 로그인 접속기록, 기기 등록·해제, 인증 변경, 특정 출금 승인 기록처럼 범위를 특정하면 쟁점이 명확하다.
다른 이용자 정보, 내부 탐지 rule, 수사 비공개 자료는 제한될 수 있다. 거절·부분 제공이면 법적 근거와 제외 field, 보존 여부를 서면으로 요청한다. 수사기관이 필요한 자료는 피해자가 직접 받는 방식과 수사상 요청 방식이 다를 수 있으므로 사건 담당자와 조율한다.
발급본의 출처와 버전을 증명한다
분쟁 제출용이면 파일명, 다운로드 URL·시각, 화면의 조회 조건, 계정 일부 식별값을 함께 기록한다. 거래소 전자문서에 발급번호·전자서명이 있다면 검증법을 확인한다. screenshot만 제출하기보다 원본 CSV와 설명표, 대표 화면을 묶는다.
재발급할 때 과거 행이 달라졌다면 schema version, 정정 공지와 export 생성 시각을 비교한다. 원본 파일을 덮어쓰지 않는다. 세무·상속처럼 장기간 필요한 기록은 계정 탈퇴나 거래지원 종료 전에 확보하고 안전한 offline backup에 보관한다.
제3자 자료와 거래소 원장을 교차한다
은행 원화 거래내역, blockchain explorer, 개인 wallet history를 거래소 export와 맞춘다. tx hash의 amount는 network fee와 거래소 credited amount가 다를 수 있고 batch withdrawal은 한 hash에 여러 이용자가 포함될 수 있다. 차이가 곧 조작을 뜻하지 않으므로 fee·batch·internal transfer 설명을 확인한다.
최종 사건표에는 각 행의 source를 표시한다. 거래소 제공, 은행 제공, onchain 확인, 본인 메모를 분리하면 증거 강도가 보인다. 원화 환산은 사용 목적에 맞는 공식 기준과 시각을 별도 기록하며 거래소 체결가를 임의로 모든 이동에 적용하지 않는다.
자주 묻는 질문
거래내역 CSV 하나면 세금 신고 자료가 충분한가요?
항상 그렇지 않다. 체결·수수료·입출고 원가와 비거래 변동, 적용 세법상 자료를 함께 확인한다.
거래소가 보관한 모든 로그를 받을 수 있나요?
보관 의무와 고객 발급 범위는 다르다. 개인정보 열람·약관·수사 또는 소송 절차별 범위를 확인한다.
CSV를 Excel로 열어 저장해도 원본인가요?
형식과 긴 식별자가 변할 수 있다. 내려받은 원본을 수정 없이 보존하고 작업용 사본을 만든다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
