{"success":true,"regulation":"RG CNV N° 1058/25 - Capítulo III Título XIV (PSAV)","tenant_scope":{"is_filtered":false,"message":"Consolidado Multi-Tenant de Infraestructura. Use ?tenant=[slug] para aislar por PSAV."},"available_tenants":[{"id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","name":"Master / Demo","slug":"master-root","url_filter":"/api/cnv/proof-of-reserves?tenant=master-root"},{"id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","name":"Cash Inversiones","slug":"cashinversiones","url_filter":"/api/cnv/proof-of-reserves?tenant=cashinversiones"},{"id":"d3b07384-d113-49ec-a633-8a39e94b7f21","name":"Demo reDeFinX","slug":"demo-redefinx","url_filter":"/api/cnv/proof-of-reserves?tenant=demo-redefinx"},{"id":"b71c1000-0000-4000-8000-000000000001","name":"Viki Pay","slug":"vikipay","url_filter":"/api/cnv/proof-of-reserves?tenant=vikipay"},{"id":"da700000-0000-4000-8000-000000000001","name":"teserva.","slug":"davnext","url_filter":"/api/cnv/proof-of-reserves?tenant=davnext"},{"id":"c8201000-0000-4000-8000-000000000001","name":"Telecentro","slug":"telecentro","url_filter":"/api/cnv/proof-of-reserves?tenant=telecentro"},{"id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","name":"FarmaTK","slug":"farmatk","url_filter":"/api/cnv/proof-of-reserves?tenant=farmatk"}],"psav_disclosure":{"legal_entity":"Cash Finanzas S.A. (Cash Inversiones)","cuit":"30-71694323-9","legal_domicile":"Av. Hipólito Yrigoyen 146, Piso 7°, Ciudad de Córdoba","operative_domicile":"Av. Hipólito Yrigoyen 146, Piso 7°, Ciudad de Córdoba","web_domain_ar":"https://core.redefinx.com","cnv_psav_registry_number":"PSAV N° 70 — Registro CNV","cnv_registration_status":"REGISTRADO","authorized_categories":[1,2,3,4],"category_5_primary_issuance_policy":"Habilitada para Categorías 1° a 4°. Categoría 5° deshabilitada por política interna.","subscribed_capital_ars":150000000,"minimum_net_worth_required_usd":150000,"board_president_name":"Directorio Cash Finanzas S.A.","board_alternate_director_name":"Dirección Suplente Cash Finanzas S.A.","beneficial_owner_disclosure":"Accionistas declarados en Registro CNV PSAV N° 70","infrastructure_role":"Proveedor Tecnológico y de Infraestructura Institucional (PSAVaaS Core)","framework_compliance":"RG CNV N° 1058/25 (Art. 5, 14, 15, 16, 17, 18, 19, 20, 21, 25, 29, 30, 31, 35, 36 y 37) & UIF Res. 49/2024","cnv_art5_legend":"Cash Finanzas S.A. (CUIT 30-71694323-9) se encuentra inscripta en el Registro de Proveedores de Servicios de Activos Virtuales (PSAV) de la COMISIÓN NACIONAL DE VALORES bajo el N° 70. La inscripción en dicho registro es a los fines del control como Sujeto Obligado ante la Unidad de Información Financiera (UIF) y no implica licencia, garantía ni supervisión por parte de la COMISIÓN NACIONAL DE VALORES sobre la actividad realizada (Art. 5 RG CNV N° 1058/25).","current_tnc_version":"v1.0-CASH-CNV1058","current_art36_version":"v1.0-CASH-ART36","regulatory_compliance_officer_art21":{"full_name":"Responsable de Cumplimiento Regulatorio Cash Finanzas S.A.","role":"Responsable de Cumplimiento Regulatorio y Control Interno","email":"compliance@cashinversiones.com.ar"},"public_relations_officer":{"full_name":"Responsable de Relaciones con el Público Cash Finanzas S.A.","role":"Responsable de Relaciones con el Público (Art. 29 RG 1058/25)","email":"atencionalcliente@cashinversiones.com.ar","phone":"+54 351 500-0000","claims_sla_days":10,"cnv_escalation_info":"CNV Oficial"},"uif_compliance_officer":{"full_name":"Oficial de Cumplimiento UIF Cash Finanzas S.A.","role":"Oficial de Cumplimiento PLA/FT/FPADM","email":"uif@cashinversiones.com.ar"},"custody_policy_art14_17":{"custody_modality":"HIBRIDA_PROPIA_Y_TERCEROS","wallet_categories_enabled":["BOVEDA","TRANSACCIONAL","RECAUDADORA"],"wallet_supports_enabled":["HARDWARE_HSM_MPC","SOFTWARE_SMART_ACCOUNT_ERC4337"],"multisig_scheme":"2_OF_3","multisig_cold_threshold_usd":10000,"distribution_ratio_pct":{"hot_wallet_max_pct":10,"warm_wallet_max_pct":20,"cold_vault_min_pct":70},"whitelist_mandatory":true,"whitelist_cooldown_hours":24},"fee_schedule_art31":{"custody_maintenance_fee":"0.00% (Bonificado)","internal_p2p_transfer_fee":"0.50% (Transferencia Interna Corporativa)","swap_spread_max_bps":"Hasta 150 bps (1.50%) incluido en cotización firme","fiat_on_off_ramp_fee":"0.00% Ingreso • 0.80% Egreso CBU/CVU","blockchain_withdrawal_fee":"1.00% + Costo de Red (Gas On-Chain) pre-informado"}},"audit_summary":{"total_currency_pools_verified":66,"zero_sum_invariance_certified":false,"memorandum_segregation_plane":"MEMORANDUM_CLIENT (Cuentas de Orden Art. 16)","patrimonial_segregation_plane":"PATRIMONIAL_OWN (Patrimonio Propio PSAV Art. 16)","timestamp":"2026-10-26T23:38:22.478Z"},"orders_book_m01_audit":{"total_orders_audited":50,"sealed_orders_sha256_count":50,"worm_trigger_active":true,"worm_trigger_name":"trg_immutable_orders_book_art11","cat5_security_gate_trigger":"trg_enforce_cat5_security_gate","ntp_stratum1_protocol":"AWS Time Sync Service (169.254.169.123) • ISO 8601 UTC-3","decimal_precision_policy":"NUMERIC(36, 18) • Decimal.js (36 dígitos) • v2_strict_decimal","by_psav_category":{"cat_1_fiat_av":1,"cat_2_swap_av_av":6,"cat_3_transfer_av":43,"cat_4_custody_av":0,"cat_5_primary_issuance":0}},"reserves":[{"tenant_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","tenant_name":"FarmaTK","currency":"ARS","client_accounts_count":4,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"7500000000","patrimonial_own_equity":"-7500000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00","omnibus_custody_asset":"75000000.00","patrimonial_own_equity":"-75000000.00","net_zero_sum_verification":"0.00"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"fcdb572b7e90c4627e89e17f21ee97c2be09fa20effda2a0627c6b21e7de3275","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","tenant_name":"FarmaTK","currency":"BRL","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"50000000","patrimonial_own_equity":"-50000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"50.000000","patrimonial_own_equity":"-50.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"68310535ac40c0dfa1dffe433871333917df3822b0f79f732e085f1b936c63fe","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","tenant_name":"FarmaTK","currency":"ETH","client_accounts_count":1,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00000000","omnibus_custody_asset":"0.00000000","patrimonial_own_equity":"0.00000000","net_zero_sum_verification":"0.00000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"599062a7d0e56534e72685301f1d8877f0b7840f9680d3f7a06369bee5018cd4","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","tenant_name":"FarmaTK","currency":"FTK","client_accounts_count":1,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"020dde173942fedb5a41773acdda257d013fe3502d36f85c5cf1c9d6e81678b5","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","tenant_name":"FarmaTK","currency":"PYG","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"500000000","patrimonial_own_equity":"-500000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"500.000000","patrimonial_own_equity":"-500.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"5d56530e012d219c80950e5e73544390ef7d4c66d8d3b0f356e9c32727f644ce","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","tenant_name":"FarmaTK","currency":"TRX","client_accounts_count":1,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"8cbc64a135848caf8f43fdf90db7f7f7157de45e6daba228a8abebe56834790b","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","tenant_name":"FarmaTK","currency":"USD","client_accounts_count":1,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00","omnibus_custody_asset":"0.00","patrimonial_own_equity":"0.00","net_zero_sum_verification":"0.00"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"ee40e0583a666103f994a61a305d13e08546644b42781099aae5fee229b5d698","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","tenant_name":"FarmaTK","currency":"USDC","client_accounts_count":1,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"9851002a52fc669dfac50ddae10823d6fa1374aeb033c3af2c7a4d8974ecb9d4","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","tenant_name":"FarmaTK","currency":"USDT","client_accounts_count":7,"raw":{"memorandum_client_liability":"1000","omnibus_custody_asset":"1000","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.001000","omnibus_custody_asset":"0.001000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"4743b8058e47e5ef5e489d77e8eda93fdcd065b805e1260e0e8b561a094cba96","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","tenant_name":"FarmaTK","currency":"YOMILES","client_accounts_count":1,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"eb834faceaab9098d41d59a09912d7297be42ded4bd71bf969da1d5cebddddfa","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","tenant_name":"FarmaTK","currency":"YOPOINTS","client_accounts_count":1,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"e764f6b0902309ea9010688b8d07b3b2c17bfdfe9f63176a7ad0bf99fc071a0e","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","tenant_name":"Cash Inversiones","currency":"ARS","client_accounts_count":20,"raw":{"memorandum_client_liability":"4988004743","omnibus_custody_asset":"7521741969","patrimonial_own_equity":"-12509695712","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"49880047.43","omnibus_custody_asset":"75217419.69","patrimonial_own_equity":"-125096957.12","net_zero_sum_verification":"0.00"},"reserve_coverage_ratio_pct":150.7966,"is_zero_sum_balanced":true,"merkle_root_hash":"812713c39d47ec32e50618127e01ca1ce25018108d3a4dd13a30c9c7aa699b1e","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","tenant_name":"Cash Inversiones","currency":"BRL","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"49910000","patrimonial_own_equity":"-49910000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"49.910000","patrimonial_own_equity":"-49.910000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"a57639ce99a7caf7bec24e314c5d252d79e024833b9721835e47a4fcfbd6737d","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","tenant_name":"Cash Inversiones","currency":"ETH","client_accounts_count":4,"raw":{"memorandum_client_liability":"259999999999999990","omnibus_custody_asset":"554511456839999900","patrimonial_own_equity":"0","net_zero_sum_verification":"-294511456839999910"},"formatted":{"memorandum_client_liability":"0.25999999","omnibus_custody_asset":"0.55451145","patrimonial_own_equity":"0.00000000","net_zero_sum_verification":"-0.29451145"},"reserve_coverage_ratio_pct":213.2736,"is_zero_sum_balanced":false,"merkle_root_hash":"f2ca6d1d34c6d7aa8a111e98dc6307d772e2f8bdf86774185f196632f3a8314a","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","tenant_name":"Cash Inversiones","currency":"FTK","client_accounts_count":4,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"2968b9afc47ce2ff127079cc526e8bb42ec1656bca9ca21fb33802e2cd51980a","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","tenant_name":"Cash Inversiones","currency":"PYG","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"500000000","patrimonial_own_equity":"-500000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"500.000000","patrimonial_own_equity":"-500.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"0e4e91cbc1caa1b374f1a9ecb0a32288cd0f1a36144bf14eeed6567226087876","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","tenant_name":"Cash Inversiones","currency":"TRX","client_accounts_count":4,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"49eb3402abd02a478f998cdcd3419c340d91c591d53999fbee03d57c0cf513b6","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","tenant_name":"Cash Inversiones","currency":"USD","client_accounts_count":4,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00","omnibus_custody_asset":"0.00","patrimonial_own_equity":"0.00","net_zero_sum_verification":"0.00"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"ef6b7dda3d9b55ac1b2faa952488f4de343df1bf8a0470e28249559126cd7d9f","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","tenant_name":"Cash Inversiones","currency":"USDC","client_accounts_count":4,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"ce0be0bffc03acc29f9639ed6b16f2b0be7d0a240b626d8e80d2e3599317f791","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","tenant_name":"Cash Inversiones","currency":"USDT","client_accounts_count":32,"raw":{"memorandum_client_liability":"6637430528","omnibus_custody_asset":"2971223000","patrimonial_own_equity":"-4967197528","net_zero_sum_verification":"-1300990000"},"formatted":{"memorandum_client_liability":"6637.430528","omnibus_custody_asset":"2971.223000","patrimonial_own_equity":"-4967.197528","net_zero_sum_verification":"-1300.990000"},"reserve_coverage_ratio_pct":44.7647,"is_zero_sum_balanced":false,"merkle_root_hash":"0e59f6e890aca27af65e4d8f046f353ed80416767c97e7f3d98aa3d53ffe739b","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","tenant_name":"Cash Inversiones","currency":"YOMILES","client_accounts_count":4,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"6c7d4d23bcf8e1cfea102872947d71079cd6d1cc258be241f0071e82bc8526c0","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","tenant_name":"Cash Inversiones","currency":"YOPOINTS","client_accounts_count":4,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"f77f4f82165daf0089cd40545920b5046fd037f710d535e18a297128a45522a5","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","tenant_name":"Master / Demo","currency":"ARS","client_accounts_count":4,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"7500152000","patrimonial_own_equity":"-7500000000","net_zero_sum_verification":"-152000"},"formatted":{"memorandum_client_liability":"0.00","omnibus_custody_asset":"75001520.00","patrimonial_own_equity":"-75000000.00","net_zero_sum_verification":"-1520.00"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":false,"merkle_root_hash":"55f1eb6f64cf60392c5cac047eefde1a903bfe9c70b6d35f06b948f22c68fa83","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","tenant_name":"Master / Demo","currency":"BRL","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"50000000","patrimonial_own_equity":"-50000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"50.000000","patrimonial_own_equity":"-50.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"ae07ff5f5975491a20980cc676a5369e9b8de6f302c2f165eb327aa6692ca480","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","tenant_name":"Master / Demo","currency":"ETH","client_accounts_count":2,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00000000","omnibus_custody_asset":"0.00000000","patrimonial_own_equity":"0.00000000","net_zero_sum_verification":"0.00000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"28de946ec0e3da19236adfc3affac80c2231d77037dc209659e0e41697e1a933","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","tenant_name":"Master / Demo","currency":"FTK","client_accounts_count":1,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"25000","patrimonial_own_equity":"0","net_zero_sum_verification":"-25000"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.025000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"-0.025000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":false,"merkle_root_hash":"65f3007ce24c5002fda9928bacd0e093f2555451cc4daba6359212ed9cc97f57","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","tenant_name":"Master / Demo","currency":"PYG","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"500000000","patrimonial_own_equity":"-500000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"500.000000","patrimonial_own_equity":"-500.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"3b7e4f1fa8ab9e84090862091a2d7c7f8515441545ad051dbdf575809f565d9b","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","tenant_name":"Master / Demo","currency":"TRX","client_accounts_count":1,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"4b9c67b2c443eea2ff9cdea1bd1a6af8da8b8e8a7cdf3a1351677d8a39eb60e1","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","tenant_name":"Master / Demo","currency":"USD","client_accounts_count":2,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00","omnibus_custody_asset":"0.00","patrimonial_own_equity":"0.00","net_zero_sum_verification":"0.00"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"9df77dcb1bce2867a24c8cf64071d8ef457dc1137533d3f6feb950eceed8af33","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","tenant_name":"Master / Demo","currency":"USDC","client_accounts_count":2,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"850","patrimonial_own_equity":"0","net_zero_sum_verification":"-850"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000850","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"-0.000850"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":false,"merkle_root_hash":"b4d6231b3e5a4456a48154369458a10c1c31f38082b6130793f67f1f7f49997c","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","tenant_name":"Master / Demo","currency":"USDT","client_accounts_count":4,"raw":{"memorandum_client_liability":"193010478","omnibus_custody_asset":"1250","patrimonial_own_equity":"-193010478","net_zero_sum_verification":"-1250"},"formatted":{"memorandum_client_liability":"193.010478","omnibus_custody_asset":"0.001250","patrimonial_own_equity":"-193.010478","net_zero_sum_verification":"-0.001250"},"reserve_coverage_ratio_pct":0.0006,"is_zero_sum_balanced":false,"merkle_root_hash":"b46d33af7cb895c06ce26c25cc4f961c852ce0d054741914088e64ca4c6e7327","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","tenant_name":"Master / Demo","currency":"YOMILES","client_accounts_count":1,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"62579377692f6e9be5730ee387d832bd8f7cb23fca0a98ddd77553acf059282b","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","tenant_name":"Master / Demo","currency":"YOPOINTS","client_accounts_count":1,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"1605e26ace0fcf43bb9cc3f883f4ee4252a923332dafc108375c8f9caf1e1fa5","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"b71c1000-0000-4000-8000-000000000001","tenant_name":"Viki Pay","currency":"ARS","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"7500000000","patrimonial_own_equity":"-7500000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00","omnibus_custody_asset":"75000000.00","patrimonial_own_equity":"-75000000.00","net_zero_sum_verification":"0.00"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"b183a71595ceb22ed9f416911d2a33b8701887707e8c7a75ba77f434ce9c5a43","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"b71c1000-0000-4000-8000-000000000001","tenant_name":"Viki Pay","currency":"BRL","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"50000000","patrimonial_own_equity":"-50000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"50.000000","patrimonial_own_equity":"-50.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"9aece2783b520a1e3536d50f3e81eeec14e07ebcfa270e1c5903f7e0c78b963c","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"b71c1000-0000-4000-8000-000000000001","tenant_name":"Viki Pay","currency":"ETH","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00000000","omnibus_custody_asset":"0.00000000","patrimonial_own_equity":"0.00000000","net_zero_sum_verification":"0.00000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"c42cbe978b45471dbe62c2cebcdc4b942670ba63780327176c413f508b80dde7","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"b71c1000-0000-4000-8000-000000000001","tenant_name":"Viki Pay","currency":"PYG","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"500000000","patrimonial_own_equity":"-500000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"500.000000","patrimonial_own_equity":"-500.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"7340c823b7ebb2e215253d2b1a6ab78ebfa7b68cd5f102bcd69f4bb3debcfbee","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"b71c1000-0000-4000-8000-000000000001","tenant_name":"Viki Pay","currency":"TRX","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"89e8cd5a36c5b436a0e93b4c27693adf34735fc24b554e61b481055a96e82fc0","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"b71c1000-0000-4000-8000-000000000001","tenant_name":"Viki Pay","currency":"USD","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00","omnibus_custody_asset":"0.00","patrimonial_own_equity":"0.00","net_zero_sum_verification":"0.00"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"51de01a7edb7afb958ace264cd802ec26d565fc8bb7445d0741dfaf054469b63","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"b71c1000-0000-4000-8000-000000000001","tenant_name":"Viki Pay","currency":"USDC","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"8316b09b72c028cd3c17b0980b2d1c4bc24d2b144d718809cd681da08de65d96","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"b71c1000-0000-4000-8000-000000000001","tenant_name":"Viki Pay","currency":"USDT","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"5b6907882df762a0e51431a27fb6aa88ddb96167c7b660288246064afd9c95c9","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"c8201000-0000-4000-8000-000000000001","tenant_name":"Telecentro","currency":"ARS","client_accounts_count":2,"raw":{"memorandum_client_liability":"48520000","omnibus_custody_asset":"7548520000","patrimonial_own_equity":"-7500000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"485200.00","omnibus_custody_asset":"75485200.00","patrimonial_own_equity":"-75000000.00","net_zero_sum_verification":"0.00"},"reserve_coverage_ratio_pct":15557.5433,"is_zero_sum_balanced":true,"merkle_root_hash":"f6d6d18806323f9f9b9d7026def7713b8d6a6a7c7fae59cf9beccdd36ff8b3a1","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"c8201000-0000-4000-8000-000000000001","tenant_name":"Telecentro","currency":"BRL","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"50000000","patrimonial_own_equity":"-50000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"50.000000","patrimonial_own_equity":"-50.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"b7b14eab9413e7c106b3aacde7807f7472c71e924e75942d0aee5a27a6afcaf6","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"c8201000-0000-4000-8000-000000000001","tenant_name":"Telecentro","currency":"BTC","client_accounts_count":1,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00000000","omnibus_custody_asset":"0.00000000","patrimonial_own_equity":"0.00000000","net_zero_sum_verification":"0.00000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"67a33944e6d0684415b219ce008b41bea48b9e99b806a39257cf9c6a6dc0e805","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"c8201000-0000-4000-8000-000000000001","tenant_name":"Telecentro","currency":"ETH","client_accounts_count":1,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00000000","omnibus_custody_asset":"0.00000000","patrimonial_own_equity":"0.00000000","net_zero_sum_verification":"0.00000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"58791b717357f6dd20b3a89c2fd3fedf7e7c1b7903ddb29bae0e0e6aae47b85d","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"c8201000-0000-4000-8000-000000000001","tenant_name":"Telecentro","currency":"PYG","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"500000000","patrimonial_own_equity":"-500000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"500.000000","patrimonial_own_equity":"-500.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"35a88b1ef3fcb7ecd157cbe3c4ba29008eabaa570a09a4f4bf4f178d9dfc256d","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"c8201000-0000-4000-8000-000000000001","tenant_name":"Telecentro","currency":"TRX","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"a462737c3b6b81eded5fc87a2bf8c49771670a647ee71c004e3003add08ff572","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"c8201000-0000-4000-8000-000000000001","tenant_name":"Telecentro","currency":"USD","client_accounts_count":1,"raw":{"memorandum_client_liability":"12000","omnibus_custody_asset":"12000","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"120.00","omnibus_custody_asset":"120.00","patrimonial_own_equity":"0.00","net_zero_sum_verification":"0.00"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"f8d2307126e0922f9a22189da6a8cbc669ab4fa008279c4082343ce0346d4186","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"c8201000-0000-4000-8000-000000000001","tenant_name":"Telecentro","currency":"USDC","client_accounts_count":1,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"2b34fde88eba216cfff9e6edcb75612d5ab1ef826a0cbb2b965b62a202561426","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"c8201000-0000-4000-8000-000000000001","tenant_name":"Telecentro","currency":"USDT","client_accounts_count":1,"raw":{"memorandum_client_liability":"350000000","omnibus_custody_asset":"350000000","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"350.000000","omnibus_custody_asset":"350.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"e22b6ba383d5a17f5ea9caf4f8c843b7132719ada14118652fc13fa1f4fe41aa","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"d3b07384-d113-49ec-a633-8a39e94b7f21","tenant_name":"Demo reDeFinX","currency":"ARS","client_accounts_count":10,"raw":{"memorandum_client_liability":"9750000","omnibus_custody_asset":"7500000000","patrimonial_own_equity":"-7509750000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"97500.00","omnibus_custody_asset":"75000000.00","patrimonial_own_equity":"-75097500.00","net_zero_sum_verification":"0.00"},"reserve_coverage_ratio_pct":76923.0769,"is_zero_sum_balanced":true,"merkle_root_hash":"511341ede5fa8ba478f70a2ba22baca142d8cdfbafe153df1adfe715d4dd1f07","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"d3b07384-d113-49ec-a633-8a39e94b7f21","tenant_name":"Demo reDeFinX","currency":"BRL","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"50000000","patrimonial_own_equity":"-50000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"50.000000","patrimonial_own_equity":"-50.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"c4d63ff1668927c789b75039bf9904209c64d0985baa0fad866f2f67a46dbc85","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"d3b07384-d113-49ec-a633-8a39e94b7f21","tenant_name":"Demo reDeFinX","currency":"ETH","client_accounts_count":3,"raw":{"memorandum_client_liability":"110000000000000000","omnibus_custody_asset":"110000000000000000","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.11000000","omnibus_custody_asset":"0.11000000","patrimonial_own_equity":"0.00000000","net_zero_sum_verification":"0.00000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"a8893c4d7dfd154a0d431b51f0e9b7c23427d259cdf6896daa9924d80316c01e","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"d3b07384-d113-49ec-a633-8a39e94b7f21","tenant_name":"Demo reDeFinX","currency":"PYG","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"500000000","patrimonial_own_equity":"-500000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"500.000000","patrimonial_own_equity":"-500.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"5dc7b94d1d3ad43b60bdad245512e822d14a412fd604e870c543d4f12e7e71a5","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"d3b07384-d113-49ec-a633-8a39e94b7f21","tenant_name":"Demo reDeFinX","currency":"TRX","client_accounts_count":2,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"ea83a47548d0804f2af42866659f97cf14bd220dd98436c10c2a6e832f0266ea","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"d3b07384-d113-49ec-a633-8a39e94b7f21","tenant_name":"Demo reDeFinX","currency":"USD","client_accounts_count":2,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00","omnibus_custody_asset":"0.00","patrimonial_own_equity":"0.00","net_zero_sum_verification":"0.00"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"5e652a47cddd62cdd396f22ce6e7a4654981feecf233f6eb41385bbf71e73f16","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"d3b07384-d113-49ec-a633-8a39e94b7f21","tenant_name":"Demo reDeFinX","currency":"USDC","client_accounts_count":2,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"313a836e0bed270371fa8fee9e0619c51cbe1cc96a0e2f39c72919b1dc5d5eee","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"d3b07384-d113-49ec-a633-8a39e94b7f21","tenant_name":"Demo reDeFinX","currency":"USDT","client_accounts_count":9,"raw":{"memorandum_client_liability":"19000000","omnibus_custody_asset":"19000000","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"19.000000","omnibus_custody_asset":"19.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"0ed7a7c8f8816a5d92335181f6f1eeba38d6a6144f8325e7bcf53f0b37a0a2f8","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"da700000-0000-4000-8000-000000000001","tenant_name":"teserva.","currency":"ARS","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"7500000000","patrimonial_own_equity":"-7500000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00","omnibus_custody_asset":"75000000.00","patrimonial_own_equity":"-75000000.00","net_zero_sum_verification":"0.00"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"d0c6e5a0b2f5c362fea6f16eb3caa67cfd7e45dcb902809ec6ae0a5669ab15a7","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"da700000-0000-4000-8000-000000000001","tenant_name":"teserva.","currency":"BRL","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"50000000","patrimonial_own_equity":"-50000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"50.000000","patrimonial_own_equity":"-50.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"6d117699b1541c06d7d7dc966387643d22afbf51e6932a7aa3cf42da4a255cdb","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"da700000-0000-4000-8000-000000000001","tenant_name":"teserva.","currency":"BTC","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00000000","omnibus_custody_asset":"0.00000000","patrimonial_own_equity":"0.00000000","net_zero_sum_verification":"0.00000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"9eb9d6e0bac2d9176ff120d6c033a7c999110729e7f4df6c190d91b108d859d2","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"da700000-0000-4000-8000-000000000001","tenant_name":"teserva.","currency":"ETH","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00000000","omnibus_custody_asset":"0.00000000","patrimonial_own_equity":"0.00000000","net_zero_sum_verification":"0.00000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"631e4ec77c2a7c90b2aefe54104a99f2dee5394a062600defc2531320302b169","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"da700000-0000-4000-8000-000000000001","tenant_name":"teserva.","currency":"PYG","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"500000000","patrimonial_own_equity":"-500000000","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"500.000000","patrimonial_own_equity":"-500.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"c93d0f6c5af0dbe367d4ae4573ef0f6eade7055620176716ba74a842e68f5b34","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"da700000-0000-4000-8000-000000000001","tenant_name":"teserva.","currency":"USD","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.00","omnibus_custody_asset":"0.00","patrimonial_own_equity":"0.00","net_zero_sum_verification":"0.00"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"f047266f55da5e87220a0a719df59e8a3fccce8f8cfddbcd831c3ba330083078","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"da700000-0000-4000-8000-000000000001","tenant_name":"teserva.","currency":"USDC","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"cbce230a84ebff93a51d7d8ecf9d675326e036cc52b04b8f4994a152bc9359ff","verified_at":"2026-10-26T23:38:22.130451+00:00"},{"tenant_id":"da700000-0000-4000-8000-000000000001","tenant_name":"teserva.","currency":"USDT","client_accounts_count":0,"raw":{"memorandum_client_liability":"0","omnibus_custody_asset":"0","patrimonial_own_equity":"0","net_zero_sum_verification":"0"},"formatted":{"memorandum_client_liability":"0.000000","omnibus_custody_asset":"0.000000","patrimonial_own_equity":"0.000000","net_zero_sum_verification":"0.000000"},"reserve_coverage_ratio_pct":100,"is_zero_sum_balanced":true,"merkle_root_hash":"69aa4fc299edb1733aa8d7214dc5497334a8c57f4d1c60b304d4e57412d1d85e","verified_at":"2026-10-26T23:38:22.130451+00:00"}],"supported_assets_art37":[{"symbol":"ARB","name":"Arbitrum","network":"Arbitrum Mainnet","launch_date":"2020-01-01","days_since_launch":2490,"is_under_90_days":false,"is_active":true,"whitepaper_url":"https://docs.arbitrum.io/intro","whitepaper_sha256":"79445fdbc7a5b5c5dc1c0c0f7f29a1553d39bdcf643d5f9727f21c292c46cba2","issuer_info":"Protocolo Descentralizado","art37_risk_summary":null,"is_negotiable_security":false,"cnv_public_offering_authorized":false,"cnv_offering_resolution":null,"cat5_primary_issuance_enabled":false},{"symbol":"AVAX","name":"Avalanche","network":"Avalanche Mainnet","launch_date":"2020-01-01","days_since_launch":2490,"is_under_90_days":false,"is_active":true,"whitepaper_url":"https://www.avalabs.org/whitepapers","whitepaper_sha256":"1e6ed334281a3e51dbf332b7406745412c11a4e2285a8432ef53e25ee6d42da0","issuer_info":"Protocolo Descentralizado","art37_risk_summary":null,"is_negotiable_security":false,"cnv_public_offering_authorized":false,"cnv_offering_resolution":null,"cat5_primary_issuance_enabled":false},{"symbol":"BNB","name":"BNB","network":"BNB Mainnet","launch_date":"2020-01-01","days_since_launch":2490,"is_under_90_days":false,"is_active":true,"whitepaper_url":"https://www.bnbchain.org/en","whitepaper_sha256":"dbc128703fbc92b0ce8ef8fca4cb51be87f2ea64e72369417a6c1555bc5d2d2d","issuer_info":"Protocolo Descentralizado","art37_risk_summary":null,"is_negotiable_security":false,"cnv_public_offering_authorized":false,"cnv_offering_resolution":null,"cat5_primary_issuance_enabled":false},{"symbol":"BTC","name":"Bitcoin","network":"Bitcoin Mainnet (SegWit Bech32)","launch_date":"2009-01-03","days_since_launch":6505,"is_under_90_days":false,"is_active":true,"whitepaper_url":"https://bitcoin.org/bitcoin.pdf","whitepaper_sha256":"b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553","issuer_info":"Red Descentralizada Bitcoin (Satoshi Nakamoto)","art37_risk_summary":"Activo virtual nativo PoW descentralizado sin emisor central. Sujeto a volatilidad de mercado e irreversibilidad on-chain (Art. 36 RG CNV 1058/25).","is_negotiable_security":false,"cnv_public_offering_authorized":false,"cnv_offering_resolution":null,"cat5_primary_issuance_enabled":false},{"symbol":"DAI","name":"Dai","network":"Ethereum (ERC-20) / Polygon","launch_date":"2017-12-18","days_since_launch":3234,"is_under_90_days":false,"is_active":true,"whitepaper_url":"https://makerdao.com/es/whitepaper/","whitepaper_sha256":"4b227777d4dd1fc61c6f884f48641d02b4d121d3fd328cb08b5531fcacdabf8a","issuer_info":"MakerDAO / Sky Ecosystem","art37_risk_summary":"Moneda estable descentralizada sobrecolateralizada gobernada por contratos inteligentes de MakerDAO / Sky Ecosystem.","is_negotiable_security":false,"cnv_public_offering_authorized":false,"cnv_offering_resolution":null,"cat5_primary_issuance_enabled":false},{"symbol":"ETH","name":"Ethereum","network":"Ethereum Mainnet (Native / ERC-4337)","launch_date":"2015-07-30","days_since_launch":4106,"is_under_90_days":false,"is_active":true,"whitepaper_url":"https://ethereum.org/en/whitepaper/","whitepaper_sha256":"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855","issuer_info":"Ethereum Foundation","art37_risk_summary":"Activo virtual nativo PoS para ejecución de contratos inteligentes EVM. Sujeto a riesgos de mercado, gas dinámico y finalidad de consenso.","is_negotiable_security":false,"cnv_public_offering_authorized":false,"cnv_offering_resolution":null,"cat5_primary_issuance_enabled":false},{"symbol":"HBAR","name":"Hedera","network":"Hedera Mainnet","launch_date":"2020-01-01","days_since_launch":2490,"is_under_90_days":false,"is_active":true,"whitepaper_url":"https://hedera.com/papers","whitepaper_sha256":"09ce10d165a0254901fe4effb0a33479f197fac046d640541559faa44f1e956e","issuer_info":"Protocolo Descentralizado","art37_risk_summary":null,"is_negotiable_security":false,"cnv_public_offering_authorized":false,"cnv_offering_resolution":null,"cat5_primary_issuance_enabled":false},{"symbol":"OP","name":"Optimism","network":"Optimism Mainnet","launch_date":"2020-01-01","days_since_launch":2490,"is_under_90_days":false,"is_active":true,"whitepaper_url":"https://optimism.io/vision","whitepaper_sha256":"3aa4a86428d3d52e411122bec67f5c4cf428d4b23fb04e0045455f0763378086","issuer_info":"Protocolo Descentralizado","art37_risk_summary":null,"is_negotiable_security":false,"cnv_public_offering_authorized":false,"cnv_offering_resolution":null,"cat5_primary_issuance_enabled":false},{"symbol":"POL","name":"Polygon","network":"Polygon Mainnet","launch_date":"2020-01-01","days_since_launch":2490,"is_under_90_days":false,"is_active":true,"whitepaper_url":"https://polygon.technology/papers","whitepaper_sha256":"764ddd88bc807f50adf1ae6bb4f72799d8f8b1c025392848f8a25c7dd7bbe5ae","issuer_info":"Protocolo Descentralizado","art37_risk_summary":null,"is_negotiable_security":false,"cnv_public_offering_authorized":false,"cnv_offering_resolution":null,"cat5_primary_issuance_enabled":false},{"symbol":"SOL","name":"Solana","network":"Solana Mainnet","launch_date":"2020-01-01","days_since_launch":2490,"is_under_90_days":false,"is_active":true,"whitepaper_url":"https://solana.com/solana-whitepaper.pdf","whitepaper_sha256":"7fe024e39decc97e5066946c1f21be3241d547e13fc1e61670e57df32018148f","issuer_info":"Protocolo Descentralizado","art37_risk_summary":null,"is_negotiable_security":false,"cnv_public_offering_authorized":false,"cnv_offering_resolution":null,"cat5_primary_issuance_enabled":false},{"symbol":"TRX","name":"TRON","network":"TRON Mainnet","launch_date":"2017-08-28","days_since_launch":3346,"is_under_90_days":false,"is_active":true,"whitepaper_url":"https://tron.network/static/doc/white_paper_v_2_0.pdf","whitepaper_sha256":"4e07408562bedb8b60ce05c1decfe3ad16b72230967de01f640b7e4729b49fce","issuer_info":"TRON DAO","art37_risk_summary":"Activo virtual nativo DPoS de la red TRON DAO para transferencias de alta velocidad.","is_negotiable_security":false,"cnv_public_offering_authorized":false,"cnv_offering_resolution":null,"cat5_primary_issuance_enabled":false},{"symbol":"USDC","name":"USD Coin","network":"Ethereum (ERC-20) / Polygon / Base (ERC-4337)","launch_date":"2018-09-26","days_since_launch":2952,"is_under_90_days":false,"is_active":true,"whitepaper_url":"https://www.circle.com/en/usdc","whitepaper_sha256":"2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae","issuer_info":"Circle Internet Financial LLC","art37_risk_summary":"Moneda estable colateralizada 1:1 en efectivo y bonos del Tesoro de EE.UU. emitida por Circle Internet Financial LLC.","is_negotiable_security":false,"cnv_public_offering_authorized":false,"cnv_offering_resolution":null,"cat5_primary_issuance_enabled":false},{"symbol":"USDT","name":"Tether","network":"Ethereum (ERC-20) / TRON (TRC-20) / Polygon","launch_date":"2014-10-06","days_since_launch":4403,"is_under_90_days":false,"is_active":true,"whitepaper_url":"https://tether.to/en/whitepaper/","whitepaper_sha256":"8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac88b59b2dc327aa4","issuer_info":"Tether Operations Limited","art37_risk_summary":"Moneda estable colateralizada en reservas fiduciarias emitida por Tether Operations Limited. Sujeta a riesgo de emisor y contraparte (Art. 36 inc. i).","is_negotiable_security":false,"cnv_public_offering_authorized":false,"cnv_offering_resolution":null,"cat5_primary_issuance_enabled":false},{"symbol":"WBTC","name":"Wrapped Bitcoin","network":"Wrapped Bitcoin Mainnet","launch_date":"2020-01-01","days_since_launch":2490,"is_under_90_days":false,"is_active":true,"whitepaper_url":"https://wbtc.network/assets/wrapped-tokens-whitepaper.pdf","whitepaper_sha256":"bc564d23ecd250b02af0531955d7d6219d782783077fd864efff0d659d5644c6","issuer_info":"Protocolo Descentralizado","art37_risk_summary":null,"is_negotiable_security":false,"cnv_public_offering_authorized":false,"cnv_offering_resolution":null,"cat5_primary_issuance_enabled":false}],"third_party_agreements_art35":[{"id":"d9d79126-9dff-46ef-9a15-3c51e5b8fc88","corporate_id":"da700000-0000-4000-8000-000000000001","provider_name":"reDeFinX (YoFintech FaaS Core)","provider_legal_name":"Proveedora Tecnológica FaaS (Motor Core Multi-Tenant)","provider_tax_id":"Contrato Maestro B2B FaaS","service_type":"SAAS","criticality_level":"CRITICAL","cnv_art35_category":"PLATAFORMA_CORE_FAAS","contractual_relationship_psav":"FIRMA_DIRECTA_PSAV","who_signs_contract":"FIRMA DIRECTA: DAV NEXT S.A. firma el Convenio Maestro de Provisión Tecnológica FaaS y Delegación Operativa (Art. 35 RG 1058/25) con nosotros. Se adjunta completo en el Punto 6 del TAD.","jurisdiction_country":"República Argentina (Miembro Pleno GAFI)","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Proveedor integral del Libro Electrónico de Partida Doble SHA-256 (Art. 11 y 27), Libro de Órdenes al segundo, Motor de Perfiles Transaccionales PLAyFT (Título XI), Prueba de Reserva Merkle (Art. 15) y Portal White-Label.","sefyc_dossier_hash":"SHA256:DAVNEXT-FAAS-MASTER-ART35-2026"},{"id":"8c9f1927-baaa-4110-b3e3-f7f9957a457d","corporate_id":"da700000-0000-4000-8000-000000000001","provider_name":"Banco Coinag S.A.","provider_legal_name":"Banco Coinag S.A. (Entidad Financiera BCRA)","provider_tax_id":"30-69226678-5","service_type":"SPONSOR_BANK","criticality_level":"CRITICAL","cnv_art35_category":"RIEL_BANCARIO_FIDUCIARIO","contractual_relationship_psav":"FIRMA_DIRECTA_PSAV","who_signs_contract":"FIRMA DIRECTA: DAV NEXT S.A. abre cuenta recaudadora / convenio fiduciario a su propio CUIT (30-71960008-1) para Cuentas de Orden Fiat (Art. 18). Nuestra plataforma se conecta vía API/Webhooks homologados.","jurisdiction_country":"República Argentina (Supervisado por BCRA / UIF)","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Entidad financiera autorizada por el BCRA donde se radican los fondos fiduciarios (ARS/USD) de terceros en Cuentas de Orden (Art. 18 RG CNV 1058/25) y liquidación CBU/CVU.","sefyc_dossier_hash":"SHA256:DAVNEXT-COINAG-FIAT-ART18-2026"},{"id":"6985f456-73ca-498d-925d-dc0475c6c2d0","corporate_id":"da700000-0000-4000-8000-000000000001","provider_name":"Bit2Me (Bitcoinforme S.L.)","provider_legal_name":"Bitcoinforme S.L. (VASP Registrado Banco de España N° D592 / MiCA)","provider_tax_id":"NIF B-54835301","service_type":"CORE_BANKING","criticality_level":"CRITICAL","cnv_art35_category":"LIQUIDEZ_Y_SUBCUSTODIA_AV","contractual_relationship_psav":"CONVENIO_MAESTRO_FAAS_ART35","who_signs_contract":"DECLARACIÓN ART. 35: Opera integrado en nuestra capa de liquidez y subcustodia institucional (o mediante subcuenta corporativa dedicada a DAV NEXT S.A.). Se declara en el Punto 6 del TAD cumpliendo jurisdicción GAFI (España).","jurisdiction_country":"España — Unión Europea (Jurisdicción Cooperante GAFI / OCDE)","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Proveedor institucional de liquidez mayorista, ejecución de órdenes (Categorías 1° y 2°) y subcustodia segregada en frío/caliente (Categoría 4°) bajo regulación europea MiCA y Banco de España.","sefyc_dossier_hash":"SHA256:DAVNEXT-BIT2ME-CUSTODY-ART35-2026"},{"id":"73f5c332-25bc-48f2-a405-379b26e4e96e","corporate_id":"d3b07384-d113-49ec-a633-8a39e94b7f21","provider_name":"YoFintech SaaS Core","provider_legal_name":"YoFintech SaaS Core","provider_tax_id":"N/A","service_type":"SAAS","criticality_level":"CRITICAL","cnv_art35_category":"INFRAESTRUCTURA_TECNOLOGICA","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"Cubierto bajo Convenio Maestro de Provisión Tecnológica FaaS (Art. 35)","jurisdiction_country":"Argentina / Cooperante GAFI","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Exportación programada en caliente de esquemas PostgreSQL y Ledger en formato abierto JSON/CSV sin bloqueo de datos.","sefyc_dossier_hash":"SHA256:YOFINTECH-CORE-SECCION10-2026"},{"id":"966d716f-38da-4260-9ad6-d4ca9b69c33e","corporate_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","provider_name":"Banco Coinag S.A.","provider_legal_name":"Banco Coinag S.A.","provider_tax_id":"N/A","service_type":"SPONSOR_BANK","criticality_level":"CRITICAL","cnv_art35_category":"INFRAESTRUCTURA_TECNOLOGICA","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"Cubierto bajo Convenio Maestro de Provisión Tecnológica FaaS (Art. 35)","jurisdiction_country":"Argentina / Cooperante GAFI","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Migración de saldos a la vista mediante orden judicial o transferencia masiva CBU hacia entidad bancaria sucesora.","sefyc_dossier_hash":"SHA256:COINAG-SPONSOR-SECCION10-2026"},{"id":"aa7b6977-68a6-4a21-bd72-7ca367c3d260","corporate_id":"da700000-0000-4000-8000-000000000001","provider_name":"Supabase Inc. / Amazon Web Services (AWS)","provider_legal_name":"Supabase Inc. & Amazon Web Services Inc.","provider_tax_id":"US Cloud Infrastructure (SOC2 Type II / ISO 27001)","service_type":"IAAS","criticality_level":"CRITICAL","cnv_art35_category":"CLOUD_DB_WORM","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"NO REQUIERE FIRMA DIRECTA DE DAV NEXT: Subprocesador cloud del motor FaaS declarado en el Manual de Sistemas (Art. 12), Ciberseguridad (Art. 13) y Conservación por 10 Años (Art. 38).","jurisdiction_country":"Estados Unidos / Brasil (Miembros Plenos GAFI)","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Alojamiento de Base de Datos PostgreSQL con aislamiento Row Level Security (RLS) por tenant, Point-in-Time Recovery (PITR), backups encriptados AES-256 y retención WORM por 10 años.","sefyc_dossier_hash":"SHA256:DAVNEXT-SUPABASE-AWS-ART12-2026"},{"id":"a5ee438d-49e1-4789-b99e-f58d03cc1587","corporate_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","provider_name":"YoFintech SaaS Core","provider_legal_name":"YoFintech SaaS Core","provider_tax_id":"N/A","service_type":"SAAS","criticality_level":"CRITICAL","cnv_art35_category":"INFRAESTRUCTURA_TECNOLOGICA","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"Cubierto bajo Convenio Maestro de Provisión Tecnológica FaaS (Art. 35)","jurisdiction_country":"Argentina / Cooperante GAFI","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Exportación programada en caliente de esquemas PostgreSQL y Ledger en formato abierto JSON/CSV sin bloqueo de datos.","sefyc_dossier_hash":"SHA256:YOFINTECH-CORE-SECCION10-2026"},{"id":"04420f84-d709-4257-885d-491bed118181","corporate_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","provider_name":"Banco Coinag S.A.","provider_legal_name":"Banco Coinag S.A.","provider_tax_id":"N/A","service_type":"SPONSOR_BANK","criticality_level":"CRITICAL","cnv_art35_category":"INFRAESTRUCTURA_TECNOLOGICA","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"Cubierto bajo Convenio Maestro de Provisión Tecnológica FaaS (Art. 35)","jurisdiction_country":"Argentina / Cooperante GAFI","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Migración de saldos a la vista mediante orden judicial o transferencia masiva CBU hacia entidad bancaria sucesora.","sefyc_dossier_hash":"SHA256:COINAG-SPONSOR-SECCION10-2026"},{"id":"b6fe770d-f278-4c05-927e-d32cebba6991","corporate_id":"d3b07384-d113-49ec-a633-8a39e94b7f21","provider_name":"Banco Coinag S.A.","provider_legal_name":"Banco Coinag S.A.","provider_tax_id":"N/A","service_type":"SPONSOR_BANK","criticality_level":"CRITICAL","cnv_art35_category":"INFRAESTRUCTURA_TECNOLOGICA","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"Cubierto bajo Convenio Maestro de Provisión Tecnológica FaaS (Art. 35)","jurisdiction_country":"Argentina / Cooperante GAFI","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Migración de saldos a la vista mediante orden judicial o transferencia masiva CBU hacia entidad bancaria sucesora.","sefyc_dossier_hash":"SHA256:COINAG-SPONSOR-SECCION10-2026"},{"id":"b70fa824-d857-4ed7-9e3b-b4bf6c407763","corporate_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","provider_name":"Banco Coinag S.A.","provider_legal_name":"Banco Coinag S.A.","provider_tax_id":"N/A","service_type":"SPONSOR_BANK","criticality_level":"CRITICAL","cnv_art35_category":"INFRAESTRUCTURA_TECNOLOGICA","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"Cubierto bajo Convenio Maestro de Provisión Tecnológica FaaS (Art. 35)","jurisdiction_country":"Argentina / Cooperante GAFI","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Migración de saldos a la vista mediante orden judicial o transferencia masiva CBU hacia entidad bancaria sucesora.","sefyc_dossier_hash":"SHA256:COINAG-SPONSOR-SECCION10-2026"},{"id":"072dc28d-d957-4026-bfd0-599c4520282c","corporate_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","provider_name":"YoFintech SaaS Core","provider_legal_name":"YoFintech SaaS Core","provider_tax_id":"N/A","service_type":"SAAS","criticality_level":"CRITICAL","cnv_art35_category":"INFRAESTRUCTURA_TECNOLOGICA","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"Cubierto bajo Convenio Maestro de Provisión Tecnológica FaaS (Art. 35)","jurisdiction_country":"Argentina / Cooperante GAFI","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Exportación programada en caliente de esquemas PostgreSQL y Ledger en formato abierto JSON/CSV sin bloqueo de datos.","sefyc_dossier_hash":"SHA256:YOFINTECH-CORE-SECCION10-2026"},{"id":"03d1886c-ba38-43b2-8c71-d4430f382ab6","corporate_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","provider_name":"YoFintech SaaS Core","provider_legal_name":"YoFintech SaaS Core","provider_tax_id":"N/A","service_type":"SAAS","criticality_level":"CRITICAL","cnv_art35_category":"INFRAESTRUCTURA_TECNOLOGICA","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"Cubierto bajo Convenio Maestro de Provisión Tecnológica FaaS (Art. 35)","jurisdiction_country":"Argentina / Cooperante GAFI","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Exportación programada en caliente de esquemas PostgreSQL y Ledger en formato abierto JSON/CSV sin bloqueo de datos.","sefyc_dossier_hash":"SHA256:YOFINTECH-CORE-SECCION10-2026"},{"id":"3b53e22d-f999-48c7-9938-498ea91e5104","corporate_id":"da700000-0000-4000-8000-000000000001","provider_name":"Cloudflare Inc.","provider_legal_name":"Cloudflare Inc.","provider_tax_id":"US Cybersecurity & Edge Network (PCI-DSS / ISO 27001)","service_type":"SOC","criticality_level":"HIGH","cnv_art35_category":"CIBERSEGURIDAD_WAF","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"NO REQUIERE FIRMA DIRECTA DE DAV NEXT: DAV NEXT S.A. registra su dominio propio .ar en NIC Argentina y delega/apunta el tráfico a nuestra capa de protección perimetral Cloudflare.","jurisdiction_country":"Estados Unidos / Argentina (Miembros Plenos GAFI)","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Protección perimetral Web Application Firewall (WAF), mitigación DDoS Capa 3/4/7, validación anti-bot Turnstile y cifrado TLS 1.3 para el dominio .ar del PSAV (Art. 13 RG CNV 1058/25).","sefyc_dossier_hash":"SHA256:DAVNEXT-CLOUDFLARE-WAF-ART13-2026"},{"id":"76199659-1209-4ee8-aaf3-50139f60d971","corporate_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","provider_name":"Cloudflare Inc.","provider_legal_name":"Cloudflare Inc.","provider_tax_id":"N/A","service_type":"PAAS","criticality_level":"HIGH","cnv_art35_category":"INFRAESTRUCTURA_TECNOLOGICA","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"Cubierto bajo Convenio Maestro de Provisión Tecnológica FaaS (Art. 35)","jurisdiction_country":"Argentina / Cooperante GAFI","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Conmutación de registros DNS y WAF hacia AWS CloudFront o Fastly en menos de 15 minutos.","sefyc_dossier_hash":"SHA256:CLOUDFLARE-WAF-SECCION10-2026"},{"id":"0a820904-2922-4727-b7f1-ef8fdb0ec1ae","corporate_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","provider_name":"Cloudflare Inc.","provider_legal_name":"Cloudflare Inc.","provider_tax_id":"N/A","service_type":"PAAS","criticality_level":"HIGH","cnv_art35_category":"INFRAESTRUCTURA_TECNOLOGICA","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"Cubierto bajo Convenio Maestro de Provisión Tecnológica FaaS (Art. 35)","jurisdiction_country":"Argentina / Cooperante GAFI","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Conmutación de registros DNS y WAF hacia AWS CloudFront o Fastly en menos de 15 minutos.","sefyc_dossier_hash":"SHA256:CLOUDFLARE-WAF-SECCION10-2026"},{"id":"662af35c-1daa-40ed-828b-aabbccfd07a2","corporate_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","provider_name":"Cloudflare Inc.","provider_legal_name":"Cloudflare Inc.","provider_tax_id":"N/A","service_type":"PAAS","criticality_level":"HIGH","cnv_art35_category":"INFRAESTRUCTURA_TECNOLOGICA","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"Cubierto bajo Convenio Maestro de Provisión Tecnológica FaaS (Art. 35)","jurisdiction_country":"Argentina / Cooperante GAFI","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Conmutación de registros DNS y WAF hacia AWS CloudFront o Fastly en menos de 15 minutos.","sefyc_dossier_hash":"SHA256:CLOUDFLARE-WAF-SECCION10-2026"},{"id":"e4c7a62e-97ad-4579-9530-876541b43ea9","corporate_id":"d3b07384-d113-49ec-a633-8a39e94b7f21","provider_name":"Cloudflare Inc.","provider_legal_name":"Cloudflare Inc.","provider_tax_id":"N/A","service_type":"PAAS","criticality_level":"HIGH","cnv_art35_category":"INFRAESTRUCTURA_TECNOLOGICA","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"Cubierto bajo Convenio Maestro de Provisión Tecnológica FaaS (Art. 35)","jurisdiction_country":"Argentina / Cooperante GAFI","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Conmutación de registros DNS y WAF hacia AWS CloudFront o Fastly en menos de 15 minutos.","sefyc_dossier_hash":"SHA256:CLOUDFLARE-WAF-SECCION10-2026"},{"id":"f8ecc9f1-6043-4339-897c-522dd154aa3e","corporate_id":"da700000-0000-4000-8000-000000000001","provider_name":"Thirdweb & Pimlico / Safe (Account Abstraction ERC-4337)","provider_legal_name":"Thirdweb Inc. / Pimlico Ltd. / Safe Ecosystem Foundation","provider_tax_id":"US / UK / CH Tech Providers","service_type":"PAAS","criticality_level":"HIGH","cnv_art35_category":"INFRAESTRUCTURA_SMART_ACCOUNTS_MPC","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"NO REQUIERE FIRMA DIRECTA DE DAV NEXT: Son proveedores de infraestructura técnica de software (Smart Accounts ERC-4337, Bundler y Paymaster de Gas) contratados por nosotros e incluidos en el Anexo Técnico de nuestro Convenio FaaS.","jurisdiction_country":"EE.UU. / Reino Unido / Suiza (Miembros Plenos GAFI / OCDE)","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Infraestructura de abstracción de cuentas (ERC-4337), contratos inteligentes auditados Safe Multifirma y patrocinio de Gas (Paymaster) sin custodia de claves privadas por parte del proveedor RPC.","sefyc_dossier_hash":"SHA256:DAVNEXT-ERC4337-AA-INFRA-2026"},{"id":"27e392bd-9b9c-453f-900b-80001ba982eb","corporate_id":"da700000-0000-4000-8000-000000000001","provider_name":"Didit / Sumsub (Biometría KYC & Screening PLAyFT)","provider_legal_name":"Didit Identity / Sum and Substance Ltd.","provider_tax_id":"EU / UK RegTech Provider","service_type":"SAAS","criticality_level":"HIGH","cnv_art35_category":"BIOMETRIA_KYC_PLAYFT","contractual_relationship_psav":"SUBPROCESADOR_TECNOLOGICO_FAAS","who_signs_contract":"CUBIERTO EN CONVENIO FAAS (o cuenta propia opcional): Integrado nativamente en el flujo de Onboarding de nuestra plataforma para validación DNI/RENAPER, prueba de vida (Liveness) y cruce contra listas RePET/ONU/OFAC/PEP.","jurisdiction_country":"Unión Europea / Reino Unido (Cooperante GAFI)","is_gafi_cooperative":true,"cnv_art35_clauses_compliant":true,"tad_point6_disclosure_summary":"Motor tecnológico de identificación digital biométrica a distancia, validación documental y screening de listas restrictivas conforme a Res. UIF 49/2024 y Título XI CNV.","sefyc_dossier_hash":"SHA256:DAVNEXT-DIDIT-SUMSUB-KYC-2026"}],"legal_documents_art16_25_36":[{"id":"b80ef4f2-a7ec-42eb-8899-c99db3db9fc9","corporate_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","doc_type":"AUTONOMOUS_AGENT_TERMS_AND_ART36","version_tag":"v1.0-AP2-2026","title":"Términos de Mandato Agéntico Verificable (AP2) y Advertencia de Riesgos CNV RG 1058/25 Art. 36","normative_reference":"RG CNV N° 1058/25","summary_markdown":"Al activar su Agente Operador Autónomo, el Titular instruye la apertura de una subcuenta separada para los fondos del agente (AGENT_EXPENSE_BOX) en el Libro Mayor V5. El Agente no posee acceso de débito hacia terceros sobre la Cuenta Principal (MAIN). Toda orden que exceda los topes por transacción o diarios requerirá firma biométrica humana (HITL). El Titular puede revocar el mandato y devolver el 100% de los fondos del agente a su Cuenta Principal en 1 clic.","sha256_hash":"SHA256:385E74C59E403A45FEB68D26B828858F7801723672B33FD331E50AED4C1028B3","board_approval_act":"Acta Directorio FaaS AP2-2026","effective_from":"2026-10-24T17:16:46.979817+00:00","is_active":true},{"id":"e8533bb9-bdee-4d36-baa1-283474f2f7e7","corporate_id":"da700000-0000-4000-8000-000000000001","doc_type":"AUTONOMOUS_AGENT_TERMS_AND_ART36","version_tag":"v1.0-AP2-2026","title":"Términos de Mandato Agéntico Verificable (AP2) y Advertencia de Riesgos CNV RG 1058/25 Art. 36","normative_reference":"RG CNV N° 1058/25","summary_markdown":"Al activar su Agente Operador Autónomo, el Titular instruye la apertura de una subcuenta separada para los fondos del agente (AGENT_EXPENSE_BOX) en el Libro Mayor V5. El Agente no posee acceso de débito hacia terceros sobre la Cuenta Principal (MAIN). Toda orden que exceda los topes por transacción o diarios requerirá firma biométrica humana (HITL). El Titular puede revocar el mandato y devolver el 100% de los fondos del agente a su Cuenta Principal en 1 clic.","sha256_hash":"SHA256:4DABDF5F01BE1A9D406F1E19D8ED2063896D128B4792A040D3204567906CF299","board_approval_act":"Acta Directorio FaaS AP2-2026","effective_from":"2026-10-24T17:16:46.980115+00:00","is_active":true},{"id":"9387955c-d6c0-4cb3-af9d-e35108a9f71b","corporate_id":"d3b07384-d113-49ec-a633-8a39e94b7f21","doc_type":"AUTONOMOUS_AGENT_TERMS_AND_ART36","version_tag":"v1.0-AP2-2026","title":"Términos de Mandato Agéntico Verificable (AP2) y Advertencia de Riesgos CNV RG 1058/25 Art. 36","normative_reference":"RG CNV N° 1058/25","summary_markdown":"Al activar su Agente Operador Autónomo, el Titular instruye la apertura de una subcuenta separada para los fondos del agente (AGENT_EXPENSE_BOX) en el Libro Mayor V5. El Agente no posee acceso de débito hacia terceros sobre la Cuenta Principal (MAIN). Toda orden que exceda los topes por transacción o diarios requerirá firma biométrica humana (HITL). El Titular puede revocar el mandato y devolver el 100% de los fondos del agente a su Cuenta Principal en 1 clic.","sha256_hash":"SHA256:0EF74EB8FF14A6BCABCC4CBEF8F8511514E76523E18702E1CB87BE3088F77868","board_approval_act":"Acta Directorio FaaS AP2-2026","effective_from":"2026-10-24T17:16:46.98009+00:00","is_active":true},{"id":"1bb30448-836f-4700-9ed9-644ecc85dd20","corporate_id":"c8201000-0000-4000-8000-000000000001","doc_type":"AUTONOMOUS_AGENT_TERMS_AND_ART36","version_tag":"v1.0-AP2-2026","title":"Términos de Mandato Agéntico Verificable (AP2) y Advertencia de Riesgos CNV RG 1058/25 Art. 36","normative_reference":"RG CNV N° 1058/25","summary_markdown":"Al activar su Agente Operador Autónomo, el Titular instruye la apertura de una subcuenta separada para los fondos del agente (AGENT_EXPENSE_BOX) en el Libro Mayor V5. El Agente no posee acceso de débito hacia terceros sobre la Cuenta Principal (MAIN). Toda orden que exceda los topes por transacción o diarios requerirá firma biométrica humana (HITL). El Titular puede revocar el mandato y devolver el 100% de los fondos del agente a su Cuenta Principal en 1 clic.","sha256_hash":"SHA256:C676A37A60B6ABE46DFBBC525FBFCCBAAE4F98F9B066BBE2A270289543BAAAB9","board_approval_act":"Acta Directorio FaaS AP2-2026","effective_from":"2026-10-24T17:16:46.979893+00:00","is_active":true},{"id":"5170ad69-c975-4a9c-8e50-755e1773e427","corporate_id":"b71c1000-0000-4000-8000-000000000001","doc_type":"AUTONOMOUS_AGENT_TERMS_AND_ART36","version_tag":"v1.0-AP2-2026","title":"Términos de Mandato Agéntico Verificable (AP2) y Advertencia de Riesgos CNV RG 1058/25 Art. 36","normative_reference":"RG CNV N° 1058/25","summary_markdown":"Al activar su Agente Operador Autónomo, el Titular instruye la apertura de una subcuenta separada para los fondos del agente (AGENT_EXPENSE_BOX) en el Libro Mayor V5. El Agente no posee acceso de débito hacia terceros sobre la Cuenta Principal (MAIN). Toda orden que exceda los topes por transacción o diarios requerirá firma biométrica humana (HITL). El Titular puede revocar el mandato y devolver el 100% de los fondos del agente a su Cuenta Principal en 1 clic.","sha256_hash":"SHA256:C1D6A98239CF317B9D07B20997888D01D167C9AB373AADD840D2446C8830A029","board_approval_act":"Acta Directorio FaaS AP2-2026","effective_from":"2026-10-24T17:16:46.979877+00:00","is_active":true},{"id":"34c2cc65-887f-422b-b595-875935a7d015","corporate_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","doc_type":"AUTONOMOUS_AGENT_TERMS_AND_ART36","version_tag":"v1.0-AP2-2026","title":"Términos de Mandato Agéntico Verificable (AP2) y Advertencia de Riesgos CNV RG 1058/25 Art. 36","normative_reference":"RG CNV N° 1058/25","summary_markdown":"Al activar su Agente Operador Autónomo, el Titular instruye la apertura de una subcuenta separada para los fondos del agente (AGENT_EXPENSE_BOX) en el Libro Mayor V5. El Agente no posee acceso de débito hacia terceros sobre la Cuenta Principal (MAIN). Toda orden que exceda los topes por transacción o diarios requerirá firma biométrica humana (HITL). El Titular puede revocar el mandato y devolver el 100% de los fondos del agente a su Cuenta Principal en 1 clic.","sha256_hash":"SHA256:B037F1AC2B661FB08A5D1AB209C2C44B98DBD8DCF265062D3383884AB1CA2776","board_approval_act":"Acta Directorio FaaS AP2-2026","effective_from":"2026-10-24T17:16:46.979858+00:00","is_active":true},{"id":"7b257183-86f1-4d72-a376-21c2b4073425","corporate_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","doc_type":"AUTONOMOUS_AGENT_TERMS_AND_ART36","version_tag":"v1.0-AP2-2026","title":"Términos de Mandato Agéntico Verificable (AP2) y Advertencia de Riesgos CNV RG 1058/25 Art. 36","normative_reference":"RG CNV N° 1058/25","summary_markdown":"Al activar su Agente Operador Autónomo, el Titular instruye la apertura de una subcuenta separada para los fondos del agente (AGENT_EXPENSE_BOX) en el Libro Mayor V5. El Agente no posee acceso de débito hacia terceros sobre la Cuenta Principal (MAIN). Toda orden que exceda los topes por transacción o diarios requerirá firma biométrica humana (HITL). El Titular puede revocar el mandato y devolver el 100% de los fondos del agente a su Cuenta Principal en 1 clic.","sha256_hash":"SHA256:BCCDB96E6960ED2EC00F12F7F98244C08C75F5ED198BE67AEC17395A6880A648","board_approval_act":"Acta Directorio FaaS AP2-2026","effective_from":"2026-10-24T17:16:46.974234+00:00","is_active":true},{"id":"4efeb750-36a1-4605-909d-a07aa506061e","corporate_id":"da700000-0000-4000-8000-000000000001","doc_type":"CODIGO_CONDUCTA_ART25","version_tag":"v1.0-DAVNEXT-ART25","title":"Código de Conducta Público e Integridad de Mercado — DAV NEXT S.A. (Arts. 24, 25 y 26 RG CNV 1058/25)","normative_reference":"RG CNV N° 1058/25","summary_markdown":"Código institucional de **DAV NEXT S.A.** que rige la lealtad fiduciaria, prevención de conflictos de interés, transparencia en formación de precios y prohibición absoluta de manipulación de mercado o front-running.","sha256_hash":"439aab404c13e96cd1c01043a2c27908ec67076816f41cbf558c2497345a34c4","board_approval_act":"Acta de Directorio DAV NEXT S.A. N° 01/2026","effective_from":"2026-10-13T22:29:26.837354+00:00","is_active":true},{"id":"30ba092d-0525-40ef-97f8-c30522c8797c","corporate_id":"da700000-0000-4000-8000-000000000001","doc_type":"DDJJ_RIESGOS_ART36","version_tag":"v1.0-DAVNEXT-ART36","title":"Naturaleza y riesgos a los que los clientes están expuestos al realizar operaciones con Activos Virtuales (Art. 36 RG CNV 1058/25)","normative_reference":"RG CNV N° 1058/25","summary_markdown":"De conformidad con el Artículo 36 de la Resolución General CNV N° 1058/2025, el Cliente toma conocimiento y acepta expresamente los riesgos detallados en los incisos a) al l) antes de realizar cualquier operación con Activos Virtuales a través de **DAV NEXT S.A. (CUIT 30-71960008-1)**.","sha256_hash":"6024cf51f9fe42e599fcb8a6a5c9f83930e8dc1dfcf0d598aed5ecc0c2f397c9","board_approval_act":"Acta de Directorio DAV NEXT S.A. N° 01/2026","effective_from":"2026-10-13T22:29:26.83733+00:00","is_active":true},{"id":"2b31ed50-98e9-45f4-8910-e845fdb44a2a","corporate_id":"d3b07384-d113-49ec-a633-8a39e94b7f21","doc_type":"M01_MANUAL_SISTEMAS_ORDENES_ART11","version_tag":"v2.0-CNV1058-M01","title":"Manual de Procedimientos de Sistemas Informáticos, Tratamiento de Órdenes y Registro Cronológico al Segundo (Art. 11 RG CNV N° 1058/25)","normative_reference":"RG CNV N° 1058/25","summary_markdown":"# MANUAL DE PROCEDIMIENTOS DE SISTEMAS INFORMÁTICOS, TRATAMIENTO DE ÓRDENES Y REGISTRO CRONOLÓGICO AL SEGUNDO (M01)\n## RESOLUCIÓN GENERAL CNV N° 1058/2025 — ARTÍCULO 11 | LEY N° 27.739 | RESOLUCIÓN UIF N° 49/2024\n\n- **Código de Documento**: `M01_MANUAL_SISTEMAS_ORDENES_ART11`\n- **Versión Vigente**: `v2.0-CNV1058-M01` (Producción — Homologación Técnica Área de Sistemas CNV)\n- **Entidad Sujeto Obligado / PSAV**: Configurada por Tenant en `public.corporate_cnv_psav_configs` (incluyendo **DAV NEXT S.A.** — CUIT `30-71960008-1`)\n- **Órgano de Aprobación**: Directorio de la Sociedad — Acta de Directorio Fundacional PSAV 2026\n- **Responsables de Emisión y Control**: Responsable de Cumplimiento Regulatorio y Control Interno (Art. 21 RG CNV N° 1058/25), Oficial de Cumplimiento PLA/FT (Res. UIF N° 49/2024) y Dirección de Tecnología (CTO / Idóneo Informático Art. 20)\n\n---\n\n## 1. ENCUADRE NORMATIVO Y ALCANCE INSTITUCIONAL\n\nEl presente Manual de Procedimientos de Sistemas Informáticos, Tratamiento de Órdenes y Registro Cronológico al Segundo (en adelante, el **\"Manual M01\"**) establece la arquitectura técnica, las estructuras de datos inmutables, los algoritmos de sincronización horaria, los flujos transaccionales para las **Categorías 1° a 5° de Proveedores de Servicios de Activos Virtuales (PSAV)** y los mecanismos de control de concurrencia implementados en producción en el motor transaccional (**Ledger SSOT V5**).\n\nEl diseño e implementación técnica dan cumplimiento estricto y verificable al siguiente plexo normativo de la República Argentina:\n1. **Resolución General CNV N° 1058/2025 (Título XIV, Capítulo III de las Normas de la Comisión Nacional de Valores — T.O. 2013 y mod.)**:\n   - **Artículo 4° y Artículo 4° bis de la Ley N° 25.246 (mod. por Ley N° 27.739)**: Definición y alcance de las Cinco (5) Categorías de servicios sobre Activos Virtuales.\n   - **Artículo 11 (Sistemas Informáticos y Registro Cronológico al Segundo)**: Obligación de contar con sistemas informáticos que permitan registrar en forma cronológica, al segundo y con carácter inalterable, cada oferta ingresada y cada operación registrada con sus seis (6) atributos mínimos obligatorios, así como los procedimientos técnicos aplicables a cada categoría operativa.\n   - **Artículos 14, 15, 16, 17, 18 y 19 (Segregación Patrimonial en Cuentas de Orden, Prueba de Reservas y Custodia)**: Aislamiento matemático entre el patrimonio propio del PSAV (`PATRIMONIAL_OWN`) y los fondos/activos de terceros (`MEMORANDUM_CLIENT`), conciliación 1:1, custodia multifirma y prohibición de disposición de activos de clientes sin consentimiento expreso.\n   - **Artículo 20 (Auditoría Anual de Sistemas Informáticos)**: Trazabilidad criptográfica SHA-256 auditable por profesional independiente con competencia técnica.\n   - **Artículos 24 inc. e), 26 y 31 (Prioridad Temporal FIFO, Prevención de Front-Running y Transparencia Tarifaria)**: Ejecución estricta por orden de prelación temporal y divulgación previa de comisiones y spreads.\n   - **Artículos 36 y 37 (Divulgación de Riesgos al Consumidor y Régimen de Whitepapers)**: Exigencia de aceptación previa de los 12 riesgos regulatorios (incisos `a` a `l`), publicación de fichas técnicas oficiales (*Whitepapers*) con once (11) requisitos mínimos y advertencia destacada para Activos Virtuales con antigüedad inferior a NOVENTA (90) días corridos.\n   - **Artículo 38 (Conservación de la Documentación e Inmutabilidad por 10 Años)**: Preservación íntegra bajo modalidad *Write-Once-Read-Many* (WORM) durante un plazo mínimo de DIEZ (10) años.\n2. **Ley N° 26.831 de Mercado de Capitales (Artículo 2°)**: Delimitación e incompatibilidad técnica automática respecto de Activos Virtuales que constituyan **Valores Negociables** o contratos de inversión, los cuales se encuentran bloqueados a nivel motor de base de datos salvo autorización expresa de Oferta Pública otorgada por la CNV.\n3. **Resolución UIF N° 49/2024**: Régimen de Prevención de Lavado de Activos y Financiación del Terrorismo (PLA/FT/FPADM) para PSAV, incluyendo Perfil Transaccional Dinámico indexado en Salarios Mínimos, Vitales y Móviles (SMVM), monitoreo automatizado y cumplimiento de la Regla de Viaje (*Travel Rule* >= 3 SMVM).\n4. **Comunicaciones Técnicas del BCRA (Marco 2026 para Rieles Fiduciarios y PSPCP)**: Comunicaciones \"A\" 8406 (CIMPRA), \"A\" 8411 (Balance Cero diario con sellado Merkle), \"A\" 8469 (Cuentas Puente de Recaudación Suma Cero), \"A\" 8473 (Gobernanza Anti-Fraude e Interoperabilidad) y Punto 4.1.2 del T.O. de PSPCP (Invariante de Saldo No Negativo).\n\n---\n\n## 2. ESTRUCTURA DEL REGISTRO Y PRESERVACIÓN DE DATOS (ART. 11 PÁRRAFO 1°)\n\n### 2.1. Esquema Relacional del Libro de Órdenes (`public.yohub_orders_book`) y Libro Mayor (`public.yohub_ledger_entries`)\nEl sistema preserva de manera permanente e inalterable la totalidad de las ofertas ingresadas por los clientes y las operaciones liquidadas en dos estructuras relacionales vinculadas atómicamente en PostgreSQL:\n- **`public.yohub_orders_book` (Libro Electrónico de Ofertas y Órdenes — Art. 11)**: Registra el ciclo de vida completo de cada instrucción desde el microsegundo exacto de su recepción (`order_ingested_at`) hasta su ejecución y liquidación (`registered_at`).\n- **`public.yohub_ledger_entries` (Libro Mayor de Partida Doble — Arts. 15, 16 y 20)**: Registra los asientos contables atómicos en planos segregados asociados mediante `transaction_group_id`.\n\nA continuación se detalla el mapeo campo por campo de los **SEIS (6) datos mínimos obligatorios exigidos por el Artículo 11 párrafo 1° de la RG CNV N° 1058/25**:\n\n| N° | Requisito Normativo (Art. 11 párr. 1° RG 1058/25) | Columna en `public.yohub_orders_book` | Columna en `public.yohub_ledger_entries` | Tipo de Dato y Restricción en Motor PostgreSQL |\n| :--- | :--- | :--- | :--- | :--- |\n| **1** | **Fecha, hora, minutos y segundos en que ingresaron como ofertas al sistema** | `order_ingested_at` | `order_ingested_at` | `TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp()` — Capturado en el instante de ingreso de la oferta a la API BFF. |\n| **2** | **Fecha, hora, minutos y segundos en que fueron registradas en el sistema** | `registered_at` | `settled_at` / `created_at` | `TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp()` — Invariante controlada por trigger: `registered_at >= order_ingested_at`. |\n| **3** | **Cantidad ofertada (para compra y/o venta, conversión, transferencia o custodia)** | `offered_amount`, `executed_amount`, `execution_price`, `fee_amount`, `order_type`, `psav_category` | `amount`, `amount_usd`, `fx_rate_usd`, `entry_type` | `NUMERIC(36, 18) NOT NULL` — Cero punto flotante. Categoría PSAV `SMALLINT CHECK (psav_category BETWEEN 1 AND 5)`. |\n| **4** | **Tipo de Activo Virtual (AV)** | `base_asset`, `quote_asset` | `currency` | `VARCHAR NOT NULL` — Validado contra catálogo maestro `public.yohub_products.symbol` (ej. `BTC`, `ETH`, `USDT`, `USDC`, `DAI`, `TRX`, `ARS`, `USD`). |\n| **5** | **Identificador interno o código HASH en caso de haber sido registrada en blockchain** | `order_id` (PK), `transaction_group_id`, `blockchain_tx_hash`, `record_sha256` | `entry_id` (PK), `transaction_group_id`, `account_seq`, `tx_hash`, `prev_hash`, `current_hash` | `UUID v4` para identificadores internos, `BIGINT` monótono para `account_seq`, `TEXT` para `TXID` on-chain y `VARCHAR(64)` para sello SHA-256. |\n| **6** | **Identificación del cliente (Persona Humana o Persona Jurídica)** | `user_id`, `client_tax_id`, `client_person_type` | `account_id -> yohub_accounts.user_id` | `UUID v4 NOT NULL` FK a `public.wallet_users(id)`, `client_tax_id VARCHAR(32)` (CUIT/CUIL/DNI) y `client_person_type VARCHAR(20)` (`'HUMANA'` / `'JURIDICA'`). |\n\n### 2.2. Sincronización Horaria Atómica (Protocolo NTP Estrato 1 y Estándar ISO 8601 UTC-3)\n1. **Fuente de Tiempo Oficial (`ntp_sync_source`)**: Todos los nodos de aplicación y el clúster de base de datos sincronizan su reloj del sistema mediante el protocolo **NTP (Network Time Protocol) Estrato 1** provisto por **AWS Time Sync Service (`169.254.169.123`)**, conectado a una flota de relojes atómicos de Cesio y receptores satelitales GPS redundantes, con desviación máxima controlada inferior a 1 milisegundo (< 1 ms).\n2. **Estampado al Microsegundo en Motor Transaccional**: A diferencia de la función `now()` (que congela el tiempo al inicio del bloque transaccional), los procedimientos almacenados y triggers del Libro de Órdenes y del Libro Mayor invocan **`clock_timestamp()`**, capturando el tiempo real de reloj de pared con resolución de microsegundos.\n3. **Representación y Huso Horario Oficial Argentino**: Los registros se almacenan en tipo `TIMESTAMPTZ` (UTC absoluto con desplazamiento horario) y se exponen en todas las APIs regulatorias, reportes TAD y consolas de auditoría en formato estándar **ISO 8601 (`YYYY-MM-DDTHH:mm:ss.sss-03:00`)** bajo el huso horario oficial de la República Argentina (**`America/Argentina/Buenos_Aires` — UTC-3**).\n4. **Invariante de Prelación Cronológica**: El trigger `trg_immutable_orders_book_art11` verifica en cada inserción o actualización de estado que `NEW.registered_at >= NEW.order_ingested_at`. Cualquier intento de registrar una ejecución con marca temporal anterior al ingreso de la oferta es abortado inmediatamente con la excepción `CHRONOLOGICAL_ORDER_VIOLATION_ART11`.\n\n### 2.3. Precisión Decimal Exacta y Trazabilidad de Identificadores\n1. **Prohibición Absoluta de Punto Flootante**: Queda estrictamente prohibido en toda la arquitectura el uso de tipos `FLOAT`, `REAL`, `DOUBLE PRECISION` en SQL o `parseFloat()` / `Number()` en TypeScript para cálculos monetarios.\n   - **Base de Datos (PostgreSQL)**: Todos los importes (`offered_amount`, `executed_amount`, `execution_price`, `fee_amount`, `amount`, `current_balance`, `locked_balance`) utilizan `NUMERIC(36, 18)`.\n   - **Capa BFF / Servicios (Node.js / TypeScript)**: Toda la aritmética financiera y de conversión se procesa con la librería **`Decimal.js`** configurada con `precision: 36` y redondeo determinista `Decimal.ROUND_DOWN` bajo el contrato de precisión `v2_strict_decimal`.\n   - **Capa Cliente**: Los importes se serializan como cadenas de texto (`string`) o enteros de precisión arbitraria (`BigInt`) expresados en unidades atómicas (*wei*, *satoshis*, centavos).\n2. **Asociación Unívoca con Identificadores Internos y Hashes de Blockchain**:\n   - Cada oferta recibe al ingresar un `order_id` (`UUID v4`) único.\n   - Al ejecutarse contablemente, se vincula de forma inmutable con un `transaction_group_id` (`UUID v4`) que agrupa todas las patas de partida doble en `public.yohub_ledger_entries`.\n   - Cada cuenta afectada incrementa su número de secuencia estrictamente monótono (`account_seq BIGINT`), impidiendo intercalar o reordenar operaciones históricas.\n   - En operaciones con liquidación en redes distribuidas (Categorías 3° y 4°), el campo `blockchain_tx_hash` (en `yohub_orders_book`) y `tx_hash` (en `yohub_ledger_entries`) almacena el identificador criptográfico de la transacción en la blockchain (`TXID` de 64 caracteres hexadecimales), protegido por el índice único `idx_unique_external_deposit_proof_agnostic` para impedir la doble acreditación de un mismo evento on-chain.\n\n### 2.4. Vinculación con el Legajo KYC/KYB del Cliente (Persona Humana y Persona Jurídica)\nNinguna orden puede existir de forma anónima ni disociada de su titular verificado:\n1. Toda fila en `public.yohub_orders_book` posee clave foránea obligatoria (`NOT NULL`) hacia `public.wallet_users(id)` y hacia la entidad PSAV `public.corporates(id)` (`corporate_id`).\n2. Al momento de la inserción, el trigger `fn_immutable_orders_book_art11()` consulta `public.wallet_users` y estampa de forma inmutable en la propia fila de la orden:\n   - `client_tax_id`: El número de **CUIT, CUIL o DNI** del cliente (`COALESCE(wu.cuit_cuil, wu.id_number)`).\n   - `client_person_type`: La clasificación jurídica del titular (`'HUMANA'` o `'JURIDICA'`) tomada de `wallet_users.person_type`.\n3. **Trazabilidad hacia el Legajo Documental Aislado por Sujeto Obligado**:\n   - **Personas Humanas (`client_person_type = 'HUMANA'`)**: El `user_id` enlaza con `public.global_identities`, cuyo atributo `compliance_data -> 'tenant_dossiers' -> [corporate_id]` conserva el legajo de Debida Diligencia del Cliente (biometría facial Didit v3 / Sumsub, prueba de vida, validación RENAPER, declaración jurada PEP, sujeto obligado UIF, residencia fiscal CRS/FATCA y resultado de cribado en listas RePET, ONU y OFAC).\n   - **Personas Jurídicas (`client_person_type = 'JURIDICA'`)**: El registro enlaza adicionalmente con `public.b2b_entities`, donde obran el estatuto social, acta de designación de autoridades, registro de Beneficiarios Finales (>= 10% de participación conforme Res. UIF N° 49/2024), inscripción AFIP/ARCA y poderes de los representantes legales autorizados a operar.\n\n### 2.5. Mecanismos de Inmutabilidad Criptográfica WORM y Conservación por 10 Años (Art. 38)\nPara garantizar que ninguna oferta ingresada ni operación registrada pueda ser alterada, sobrescrita o eliminada física o lógicamente durante el plazo legal mínimo de **DIEZ (10) años** (Art. 38 RG CNV N° 1058/25), la base de datos implementa tres anillos de defensa criptográfica a nivel de motor PostgreSQL:\n1. **Trigger WORM en el Libro de Órdenes (`trg_immutable_orders_book_art11`)**:\n   - Intercepta cualquier sentencia `DELETE` sobre `public.yohub_orders_book` y aborta la transacción arrojando la excepción `ART11_RG1058_DELETE_FORBIDDEN`.\n   - Intercepta cualquier sentencia `UPDATE` que intente modificar los atributos originales de la oferta (`order_id`, `corporate_id`, `user_id`, `order_type`, `psav_category`, `base_asset`, `quote_asset`, `offered_amount`, `order_ingested_at`, `client_tax_id`, `client_person_type`), abortando la transacción con `ART11_RG1058_IMMUTABILITY_VIOLATION`. Únicamente se permite la transición controlada de `status`, `executed_amount`, `registered_at`, `transaction_group_id` y `blockchain_tx_hash` cuando una orden en tránsito pasa a estado final liquidado.\n   - Calcula y sella en la columna `record_sha256` el digest criptográfico `SHA-256` (`extensions.digest(..., 'sha256')`) sobre la concatenación canónica de todos los atributos de la orden.\n2. **Trigger WORM y Cadena de Bloques Interna en el Libro Mayor (`trg_immutable_ledger_entries`)**:\n   - Prohíbe en forma absoluta cualquier `UPDATE` o `DELETE` sobre `public.yohub_ledger_entries`. Cualquier ajuste contable o reversa debe instrumentarse exclusivamente mediante un nuevo asiento compensatorio de partida doble (`CLEARING_ADJUSTMENT` o `REVERSAL`) vinculado al asiento original mediante `parent_entry_id` y `root_transaction_group_id`.\n   - Cada asiento incorpora en su cálculo de `current_hash` (`SHA-256`) el hash exacto del asiento inmediato anterior de la misma cuenta (`prev_hash`), formando una estructura encadenada donde la alteración de un solo bit histórico invalidaría toda la cadena subsiguiente.\n3. **Sellado Diario de Árbol de Merkle (`public.bcra_daily_ledger_seals`)**:\n   - Al cierre de cada jornada operativa, el motor consolida los hashes de todas las operaciones y saldos de Cuentas de Orden en una Raíz de Merkle (`merkle_root_hash` SHA-256), la cual queda asentada y disponible para verificación pública en `/api/cnv/proof-of-reserves` y `/cnv-transparencia`.\n\n---\n\n## 3. PROCEDIMIENTOS TÉCNICOS DE TRATAMIENTO DE ÓRDENES POR CATEGORÍA (ART. 11 PÁRRAFO 2° — CATEGORÍAS 1° A 5°)\n\nDe conformidad con el segundo párrafo del Artículo 11 de la RG CNV N° 1058/25 y el Artículo 4° bis de la Ley N° 25.246, se detallan a continuación los procedimientos técnicos de procesamiento para cada una de las cinco (5) categorías operativas:\n\n### 3.1. Categoría 1°: Intercambio entre Activos Virtuales y Monedas de Curso Legal (Monedas Fiduciarias ARS / USD)\nComprende las órdenes de compra (`order_type = 'BUY'`, `psav_category = 1`) y venta (`order_type = 'SELL'`, `psav_category = 1`) de Activos Virtuales contra Pesos Argentinos (`ARS`) o Dólares Estadounidenses (`USD`):\n1. **Ingreso y Conciliación de Fondos Fiduciarios (In-Ramp Bancario)**:\n   - El cliente transfiere fondos desde una cuenta bancaria o de pago de su propia titularidad hacia la cuenta recaudadora de **Cuentas de Orden** del PSAV abierta en la Entidad Financiera Patrocinadora (**Banco Coinag S.A. APIs v4.9 / Banco CMF / Red COELSA**), operando bajo el esquema de salto transaccional de **CVU Corta a CBU Larga Recaudadora** exenta del Impuesto sobre los Créditos y Débitos Bancarios conforme al **Decreto PEN N° 475/2026 y RG ARCA N° 5869/2026**.\n   - El webhook bancario autenticado (`/api/webhooks/sponsor-bank/transferencia`) verifica la regla de **Misma Titularidad (*Same-Name Rule* — BCRA Com. \"A\" 7340 y Art. 18 RG CNV 1058/25)** cotejando el CUIT/CUIL del originante informado por COELSA contra el `cuit_cuil` del legajo del usuario en `public.wallet_users`. Si los CUIT/CUIL no coinciden o provienen de terceros no autorizados, el depósito es rechazado o retenido preventivamente.\n   - El sistema almacena la evidencia forense del movimiento bancario (incluyendo la trama cruda de 180 caracteres en `public.bank_clearing_items.raw_line` durante la conciliación SFTP D-1 de lotes COELSA DEBIN Fase 4 v5.0 y Movimientos PSP 1.1) y acredita el saldo fiduciario en la cuenta `MEMORANDUM_CLIENT` del usuario.\n2. **Ingreso de la Oferta de Compra/Venta y Reserva de Saldo**:\n   - Cuando el cliente instruye la compra (`ARS -> USDT`) o venta (`USDT -> ARS`), el sistema registra la oferta en `public.yohub_orders_book` con `psav_category = 1` y `order_ingested_at = clock_timestamp()`.\n   - Se bloquea pesimistamente la cuenta de origen (`SELECT ... FOR UPDATE`) y se transfiere el monto ofertado de `current_balance` a `locked_balance`.\n3. **Calce contra Proveedor de Liquidez y Liquidación en Partida Doble**:\n   - La orden se ejecuta contra el libro interno o se rutea hacia el proveedor de liquidez institucional regulado (`Bit2Me` — convenio registrado bajo el Art. 35 RG CNV 1058/25 en `public.bcra_third_party_registry`) mediante el patrón *Transactional Outbox*.\n   - Confirmado el calce, dentro de una única transacción atómica PostgreSQL se consume el `locked_balance`, se asientan las partidas de débito y crédito en `public.yohub_ledger_entries` (verificando Suma Cero = 0 en el `transaction_group_id`), y se sella `registered_at = clock_timestamp()` y `record_sha256` en `public.yohub_orders_book`.\n4. **Egreso Fiduciario (Off-Ramp Bancario)**:\n   - En órdenes de venta con retiro fiduciario hacia CBU/CVU externo, el sistema valida previamente la titularidad de la cuenta destino en COELSA y liquida la transferencia inmediata registrando el identificador COELSA/OBID en el asiento contable.\n\n### 3.2. Categoría 2°: Intercambio entre Una o Más Formas de Activos Virtuales (Swap Cripto-a-Cripto)\nComprende las órdenes de conversión directa entre distintos Activos Virtuales (`order_type = 'SWAP'`, `psav_category = 2`, ej. `BTC <-> USDT`, `ETH <-> USDC`):\n1. **Fijación de Cotización Firme y *Quote Locking* Criptográfico (Art. 31)**:\n   - Previo a la confirmación del cliente, el motor de cotizaciones (`/api/wallet/transfer/quote` y `/api/wallet/swap-internal`) consulta el precio en tiempo real del Oráculo institucional y aplica de forma transparente el diferencial (*spread*) máximo parametrizado para el Tenant en `public.corporate_cnv_psav_configs.fee_crypto_swap_max_spread_bps` (Art. 31 RG CNV 1058/25).\n   - El servidor emite un token de cotización firmado con **HMAC-SHA256** que incluye el par (`base_asset`, `quote_asset`), la tasa exacta (`execution_price`), la comisión desglosada (`fee_amount`) y un tiempo de expiración determinista (TTL).\n2. **Prioridad Temporal Estricta FIFO (*First-In, First-Out*) Anti-Front-Running (Arts. 24 inc. e y 26)**:\n   - Las órdenes ingresadas se procesan en estricto orden cronológico de recepción según su marca temporal `order_ingested_at` y su secuencia monótona.\n   - La plataforma no realiza operaciones de *proprietary trading* con ventaja informativa ni reordena colas de ejecución, garantizando neutralidad absoluta y ausencia de *front-running*.\n3. **Asiento Contable Atómico Multi-Pata**:\n   - La función transaccional ejecuta en una sola unidad de trabajo (`BEGIN ... COMMIT`):\n     - Débito del activo entregado (`SWAP_DEBIT`) en la cuenta `MEMORANDUM_CLIENT` del usuario;\n     - Crédito del activo recibido (`SWAP_CREDIT`) en la cuenta `MEMORANDUM_CLIENT` del usuario;\n     - Contrapartida simétrica en las cuentas ómnibus segregadas (`OMNIBUS_MASTER`) de ambos activos;\n     - Imputación de la comisión devengada en la cuenta de resultados del PSAV (`REVENUE_FEE` en el plano `PATRIMONIAL_OWN`).\n   - Se registra la orden en `public.yohub_orders_book` con `psav_category = 2`, `status = 'EXECUTED'` y sello `record_sha256`.\n\n### 3.3. Categoría 3°: Transferencia de Activos Virtuales\nComprende toda instrucción de envío o recepción de Activos Virtuales (`order_type = 'TRANSFER'`, `psav_category = 3`), distinguiendo técnicamente dos modalidades:\n1. **Transferencias Internas entre Clientes en el Libro Mayor (*Off-Chain Book-Entry*)**:\n   - Cuando el destinatario es otro usuario registrado en la infraestructura (`INTERNAL_TRANSFER` o `CROSS_TENANT_TRANSFER`), la liquidación se realiza íntegramente dentro de PostgreSQL mediante la función `rpc_execute_federated_transfer`.\n   - No se incurre en costo de gas de red blockchain (comisión `0.00%` bonificada según Cuadro Tarifario Art. 31), la acreditación es instantánea (sub-segundo) y el movimiento queda asentado simultáneamente en `public.yohub_orders_book` (`psav_category = 3`) y en `public.yohub_ledger_entries`.\n2. **Transferencias Externas hacia o desde Direcciones en la Blockchain (*On-Chain Transfers*)**:\n   - **Cumplimiento Automatizado de la Regla de Viaje (*Travel Rule* — Art. 26 Res. UIF N° 49/2024)**: En toda transferencia cuyo importe en dólares estadounidenses iguale o supere el equivalente a **TRES (3) Salarios Mínimos, Vitales y Móviles (`3 * SMVM`)** —o el umbral paramétrico inferior configurado en `public.yohub_regulatory_parameters`—, el motor exige y persiste en `public.travel_rule_records` los datos completos del originante (`originator_name`, `originator_id_number`), del beneficiario (`beneficiary_name`, `beneficiary_type`), el PSAV/VASP de destino (`beneficiary_vasp_name`), la dirección de billetera (`destination_wallet_address`) y la declaración jurada de titularidad en caso de billeteras auto-custodiadas (*unhosted wallets*, `unhosted_ownership_declared`).\n   - **Compuerta de Lista Blanca Obligatoria con Enfriamiento de 24 Horas (Art. 17 inc. d RG CNV 1058/25)**: Ningún retiro on-chain puede ejecutarse hacia una dirección externa que no se encuentre previamente registrada y verificada en `public.yohub_whitelisted_addresses` para ese `user_id` y `corporate_id`, habiendo transcurrido el período de enfriamiento (*cooldown*) mínimo de **VEINTICUATRO (24) horas** parametrizado en `corporate_cnv_psav_configs.whitelist_cooldown_hours`.\n   - **Paridad Custodial vs. Non-Custodial (Smart Accounts ERC-4337)**: En billeteras de abstracción de cuenta (ERC-4337), el sistema verifica criptográficamente el recibo de ejecución y el `tx_hash` real en el nodo RPC antes de impactar el espejo contable.\n\n### 3.4. Categoría 4°: Custodia y/o Administración de Activos Virtuales\nComprende el resguardo técnico, administración de claves criptográficas, detección de depósitos on-chain (`order_type = 'CUSTODY_DEPOSIT'`, `psav_category = 4`), procesamiento de retiros (`order_type = 'CUSTODY_WITHDRAWAL'`, `psav_category = 4`) y conciliación de reservas:\n1. **Procedimiento Técnico de Detección y Acreditación de Depósitos On-Chain**:\n   - Los servicios de indexación y webhooks autenticados (`/api/webhooks/gateway/[provider]` con validación de firma criptográfica HMAC-SHA512 y control de repetición *anti-replay*) monitorean las direcciones de depósito asignadas.\n   - Para prevenir ataques de reorganización de cadena (*chain reorgs*) o doble gasto, el sistema exige alcanzar el número mínimo de confirmaciones definitivas antes de cambiar el estado a acreditado:\n     - **Red Polygon PoS**: mínimo **64 bloques** confirmados;\n     - **Red Bitcoin Mainnet**: mínimo **3 bloques** minados;\n     - **Red Ethereum Mainnet**: estado de finalidad PoS (**Finalized Checkpoint** >= 2 épocas / 64 slots);\n     - **Red TRON Mainnet (TRC-20)**: mínimo **19 bloques Solidified** confirmados por Super Representantes;\n     - **Redes Ethereum L2 (Arbitrum / Optimism / Base)**: confirmación de lote publicado en L1 (*L1 Batch Finality*).\n   - **Blindaje Anti-Emisión Ficticia (*Agnostic Proof of Deposit Invariant*)**: El trigger de base de datos valida que todo asiento `EXTERNAL_DEPOSIT` posea su prueba criptográfica de depósito verificada (`tx_hash` on-chain o referencia de cámara COELSA); cualquier intento de inyectar saldo sin respaldo arroja la excepción `UNBACKED_DEPOSIT_REJECTED`. Asimismo, el índice único `idx_unique_external_deposit_proof_agnostic` garantiza idempotencia absoluta.\n2. **Política de Custodia Térmica y Segregación en Cuentas de Orden (Arts. 14, 15, 16 y 17)**:\n   - Todos los activos de clientes se contabilizan en el plano `MEMORANDUM_CLIENT`, separados del plano `PATRIMONIAL_OWN`.\n   - La distribución física de los activos en custodia respeta la relación paramétrica auditada en `public.corporate_cnv_psav_configs`:\n     - **Bóveda Fría (*Cold Vault* — HSM / Air-Gapped / MPC)**: mínimo **70%** (`cold_vault_min_pct >= 70`);\n     - **Billetera Tibia (*Warm Wallet*)**: máximo **20%** (`warm_wallet_max_pct <= 20`);\n     - **Billetera Caliente (*Hot Wallet* transaccional)**: máximo **10%** (`hot_wallet_max_pct <= 10`);\n     - Con validación estricta Hot + Warm + Cold = 100%.\n3. **Gobernanza Multifirma por Umbral (Art. 17 inc. c) y Emisión de Retiros vía HSM/MPC**:\n   - Todo retiro o movimiento de tesorería desde custodia cuyo valor equivalente iguale o supere el umbral de seguridad parametrizado (**USD 10.000,00** en `multisig_cold_threshold_usd`) requiere obligatoriamente esquema de firma mancomunada **2-de-3 (`2_OF_3`)** registrado en `public.yohub_multisig_approvals`, con intervención de al menos dos oficiales autorizados bajo Principio de Control Dual (4 Ojos) y autenticación biométrica FIDO2/WebAuthn Level 3 antes de que el módulo HSM/MPC transmita la transacción a la red.\n\n### 3.5. Categoría 5°: Servicios Financieros Relacionados con la Oferta de un Emisor y/o Venta de un Activo Virtual (Colocación Primaria)\nComprende la participación y prestación de servicios financieros vinculados a la emisión o colocación primaria de un Activo Virtual (`order_type = 'PRIMARY_ISSUANCE'`, `psav_category = 5`):\n1. **Debida Diligencia Reforzada del Emisor y Segregación por Emisión**:\n   - Previo a habilitar cualquier proyecto en Categoría 5°, el Comité de Cumplimiento ejecuta la debida diligencia reforzada (KYB, Beneficiarios Finales, auditoría técnica del contrato inteligente y dictamen legal sobre la naturaleza jurídica del token) y requiere aprobación expresa por Acta de Directorio conforme a `category_5_primary_issuance_policy`.\n2. **Validación Previa Obligatoria del Whitepaper Oficial (Art. 37 RG CNV 1058/25)**:\n   - El activo debe encontrarse dado de alta en `public.yohub_products` cumpliendo los once (11) recaudos informativos del Artículo 37: identificación del emisor (`issuer_info`), resumen de riesgos técnicos y económicos (`art37_risk_summary`), fecha de lanzamiento (`launch_date`), enlace público permanente al documento técnico fundacional (`whitepaper_url`) y sello criptográfico de integridad de 64 caracteres hexadecimales (`whitepaper_sha256`).\n   - Cuando la antigüedad del Activo Virtual desde su `launch_date` sea inferior a **NOVENTA (90) días corridos** (`is_under_90_days = true`), la plataforma lo exhibe en una sección segregada con advertencia de riesgo reforzada conforme al último párrafo del Artículo 36.\n   - El trigger `trg_enforce_cat5_security_gate` en `public.yohub_products` y el trigger `trg_immutable_orders_book_art11` en `public.yohub_orders_book` rechazan con la excepción `CAT5_WHITEPAPER_REQUIRED_ART37` cualquier intento de activar un activo o cursar una orden `PRIMARY_ISSUANCE` si `whitepaper_url` o `whitepaper_sha256` (64 chars hex) se encuentran vacíos o incompletos.\n3. **Bloqueo Técnico Determinista de Valores Negociables sin Oferta Pública CNV (Ley N° 26.831 Art. 2)**:\n   - El catálogo de productos incluye el atributo booleano `is_negotiable_security`, el indicador `cnv_public_offering_authorized` y el campo `cnv_offering_resolution`.\n   - Si un activo representa un derecho de crédito, participación societaria, instrumento de deuda soberana/corporativa o contrato de inversión alcanzado por el **Artículo 2° de la Ley N° 26.831** (por ejemplo, el activo `TBILL_RWA` — *Tokenized US T-Bill RWA*, marcado con `is_negotiable_security = true`), **queda bloqueado determinísticamente a nivel de motor de base de datos PostgreSQL** (`is_active = false`, `cat5_primary_issuance_enabled = false`).\n   - El trigger `trg_enforce_cat5_security_gate` impide activar (`is_active = true`) o habilitar la colocación primaria (`cat5_primary_issuance_enabled = true`), y el trigger `trg_immutable_orders_book_art11` impide insertar órdenes sobre dicho activo mientras `cnv_public_offering_authorized` sea `false` o carezca de número de Resolución de Oferta Pública de la CNV (`cnv_offering_resolution`), arrojando de forma inmediata el error `SECURITY_TOKEN_REQUIRES_CNV_PUBLIC_OFFERING_AUTH`.\n\n---\n\n## 4. VALIDACIONES PRE-TRANSACCIONALES Y CONTROL DE CONCURRENCIA\n\n### 4.1. Las Seis (6) Validaciones Automáticas Pre-Transaccionales Síncronas\nNinguna oferta ingresada al sistema puede pasar a ejecución sin superar de manera síncrona y satisfactoria las siguientes seis (6) compuertas automáticas:\n1. **Compuerta 1 — Estado del Legajo KYC/KYB y Listas Restrictivas PLA/FT**: Verificación en `public.wallet_users` y `global_identities.compliance_data.tenant_dossiers[corporate_id]` de que el cliente posee estado `APPROVED` / `VERIFIED_ALL`, sin bloqueos preventivos ni alertas críticas abiertas en `public.compliance_alerts` (RePET, ONU, OFAC, GAFI).\n2. **Compuerta 2 — Aceptación Expresa de la DDJJ de Riesgos (Art. 36) y Términos de Cuentas de Orden (Art. 16)**: Verificación en `public.corporate_legal_acceptances` de que el usuario ha firmado digitalmente la versión vigente de `DDJJ_RIESGOS_ART36` (incisos `a` a `l`) y `TNC_CUENTAS_DE_ORDEN_ART16_18_19`.\n3. **Compuerta 3 — Evaluación del Perfil Transaccional Dinámico Indexado en SMVM (Res. UIF N° 49/2024)**: Invocación a la función PL/pgSQL `public.rpc_evaluate_transactional_profile`, que calcula el monto de la orden en USD y valida que no exceda:\n   - El tope máximo por transacción (`max_per_tx_usd`);\n   - El acumulado móvil de las últimas **24 horas** (`max_daily_usd`);\n   - El acumulado móvil de los últimos **30 días** (`max_monthly_usd` / multiplicador SMVM mensual);\n   - El acumulado móvil de los últimos **365 días** (`max_annual_usd` / multiplicador SMVM anual).\n4. **Compuerta 4 — Disponibilidad de Saldo Libre de Bloqueos e Invariante de Saldo No Negativo (BCRA PSPCP 4.1.2)**: Verificación matemática en precisión `NUMERIC(36, 18)` de que la cuenta de origen posee saldo disponible suficiente (`current_balance - locked_balance >= offered_amount + fee_amount`). El motor tiene prohibido otorgar descubiertos o permitir saldos negativos (`CHECK (current_balance >= 0 AND locked_balance >= 0)`).\n5. **Compuerta 5 — Reglas de Producto, Red, Travel Rule y Whitelist 24h**: Verificación de que el activo permite la dirección del flujo (`default_allow_inbound` / `default_allow_outbound`), que en retiros on-chain la dirección destino cumple las 24 horas de enfriamiento en `yohub_whitelisted_addresses` (Art. 17 inc. d) y que se ha integrado el registro de `travel_rule_records` si el monto es >= 3 SMVM.\n6. **Compuerta 6 — Compuerta de Categoría 5°, Whitepaper Art. 37 e Incompatibilidad Ley 26.831**: Verificación por los triggers `trg_enforce_cat5_security_gate` y `trg_immutable_orders_book_art11` de que el activo posee `whitepaper_sha256` válido y no constituye un Valor Negociable sin autorización de oferta pública de la CNV.\n\n### 4.2. Mecanismo de Bloqueo Transaccional Pesimista y Control de Concurrencia\nPara garantizar atomicidad (`ACID`), aislamiento serializable efectivo sobre saldos y ausencia total de condiciones de carrera (*race conditions*) o interbloqueos (*deadlocks*) bajo alta concurrencia:\n1. **Bloqueo Pesimista con Ordenamiento Lexicográfico Determinista Anti-Deadlock**:\n   - Cuando una operación involucra dos o más cuentas contables (ej. cuenta origen del cliente, cuenta destino, cuenta ómnibus y cuenta de comisiones), el procedimiento almacenado adquiere el bloqueo exclusivo de fila ejecutando:\n     ```sql\n     SELECT id, current_balance, locked_balance\n     FROM public.yohub_accounts\n     WHERE id = ANY(v_account_ids)\n     ORDER BY id ASC\n     FOR UPDATE;\n     ```\n   - Al ordenar los identificadores `UUID` en forma ascendente (`ORDER BY id ASC`) antes de adquirir los cerrojos `FOR UPDATE`, dos transacciones concurrentes cruzadas (ej. Usuario A transfiere a Usuario B al mismo milisegundo en que Usuario B transfiere a Usuario A) solicitan los bloqueos exactamente en el mismo orden canónico, **eliminando matemáticamente la posibilidad de un ciclo de espera (*deadlock*)**.\n2. **Reserva Atómica de Saldo en Tránsito (`locked_balance` — Saga Fase 1)**:\n   - En operaciones asíncronas que dependen de confirmación externa (liquidación en blockchain o cámara compensadora bancaria), la Fase 1 deduce el importe de `current_balance` o lo compromete en `locked_balance` dentro de la misma transacción en que la orden ingresa a `yohub_orders_book` (`status = 'PENDING_SETTLEMENT'`). Si el cliente envía múltiples peticiones simultáneas (*double-click* o ataque de concurrencia), la segunda petición encuentra el cerrojo `FOR UPDATE` y, al liberarse, verifica el saldo ya disminuido, siendo rechazada de inmediato por saldo insuficiente.\n3. **Secuencia Monótona por Cuenta (`account_seq`) e Invariante Diferida de Suma Cero**:\n   - Cada inserción en `public.yohub_ledger_entries` asigna `account_seq = COALESCE(MAX(account_seq), 0) + 1` bajo el cerrojo de la cuenta.\n   - Al finalizar la transacción (`DEFERRABLE INITIALLY DEFERRED`), el constraint trigger `fn_enforce_zero_sum_transaction_group` comprueba que la suma algebraica de todos los movimientos del `transaction_group_id` por moneda sea exactamente igual a cero (`SUM(amount) = 0.000000000000000000`). En caso de discrepancia de siquiera 1e-18 unidades, la transacción completa hace `ROLLBACK` automático.\n","sha256_hash":"SHA256:051B2EC29EE7DF42850A8AADC9CCE01C062376C0B589D5A85628F5356B4D20E4","board_approval_act":"Acta de Directorio PSAV 2026 — Aprobación Manual Técnico M01 (Art. 11 RG CNV N° 1058/25)","effective_from":"2026-10-16T21:40:40.208811+00:00","is_active":true},{"id":"0993114f-0b51-451a-9cbb-d7d5c94c37fa","corporate_id":"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11","doc_type":"M01_MANUAL_SISTEMAS_ORDENES_ART11","version_tag":"v2.0-CNV1058-M01","title":"Manual de Procedimientos de Sistemas Informáticos, Tratamiento de Órdenes y Registro Cronológico al Segundo (Art. 11 RG CNV N° 1058/25)","normative_reference":"RG CNV N° 1058/25","summary_markdown":"# MANUAL DE PROCEDIMIENTOS DE SISTEMAS INFORMÁTICOS, TRATAMIENTO DE ÓRDENES Y REGISTRO CRONOLÓGICO AL SEGUNDO (M01)\n## RESOLUCIÓN GENERAL CNV N° 1058/2025 — ARTÍCULO 11 | LEY N° 27.739 | RESOLUCIÓN UIF N° 49/2024\n\n- **Código de Documento**: `M01_MANUAL_SISTEMAS_ORDENES_ART11`\n- **Versión Vigente**: `v2.0-CNV1058-M01` (Producción — Homologación Técnica Área de Sistemas CNV)\n- **Entidad Sujeto Obligado / PSAV**: Configurada por Tenant en `public.corporate_cnv_psav_configs` (incluyendo **DAV NEXT S.A.** — CUIT `30-71960008-1`)\n- **Órgano de Aprobación**: Directorio de la Sociedad — Acta de Directorio Fundacional PSAV 2026\n- **Responsables de Emisión y Control**: Responsable de Cumplimiento Regulatorio y Control Interno (Art. 21 RG CNV N° 1058/25), Oficial de Cumplimiento PLA/FT (Res. UIF N° 49/2024) y Dirección de Tecnología (CTO / Idóneo Informático Art. 20)\n\n---\n\n## 1. ENCUADRE NORMATIVO Y ALCANCE INSTITUCIONAL\n\nEl presente Manual de Procedimientos de Sistemas Informáticos, Tratamiento de Órdenes y Registro Cronológico al Segundo (en adelante, el **\"Manual M01\"**) establece la arquitectura técnica, las estructuras de datos inmutables, los algoritmos de sincronización horaria, los flujos transaccionales para las **Categorías 1° a 5° de Proveedores de Servicios de Activos Virtuales (PSAV)** y los mecanismos de control de concurrencia implementados en producción en el motor transaccional (**Ledger SSOT V5**).\n\nEl diseño e implementación técnica dan cumplimiento estricto y verificable al siguiente plexo normativo de la República Argentina:\n1. **Resolución General CNV N° 1058/2025 (Título XIV, Capítulo III de las Normas de la Comisión Nacional de Valores — T.O. 2013 y mod.)**:\n   - **Artículo 4° y Artículo 4° bis de la Ley N° 25.246 (mod. por Ley N° 27.739)**: Definición y alcance de las Cinco (5) Categorías de servicios sobre Activos Virtuales.\n   - **Artículo 11 (Sistemas Informáticos y Registro Cronológico al Segundo)**: Obligación de contar con sistemas informáticos que permitan registrar en forma cronológica, al segundo y con carácter inalterable, cada oferta ingresada y cada operación registrada con sus seis (6) atributos mínimos obligatorios, así como los procedimientos técnicos aplicables a cada categoría operativa.\n   - **Artículos 14, 15, 16, 17, 18 y 19 (Segregación Patrimonial en Cuentas de Orden, Prueba de Reservas y Custodia)**: Aislamiento matemático entre el patrimonio propio del PSAV (`PATRIMONIAL_OWN`) y los fondos/activos de terceros (`MEMORANDUM_CLIENT`), conciliación 1:1, custodia multifirma y prohibición de disposición de activos de clientes sin consentimiento expreso.\n   - **Artículo 20 (Auditoría Anual de Sistemas Informáticos)**: Trazabilidad criptográfica SHA-256 auditable por profesional independiente con competencia técnica.\n   - **Artículos 24 inc. e), 26 y 31 (Prioridad Temporal FIFO, Prevención de Front-Running y Transparencia Tarifaria)**: Ejecución estricta por orden de prelación temporal y divulgación previa de comisiones y spreads.\n   - **Artículos 36 y 37 (Divulgación de Riesgos al Consumidor y Régimen de Whitepapers)**: Exigencia de aceptación previa de los 12 riesgos regulatorios (incisos `a` a `l`), publicación de fichas técnicas oficiales (*Whitepapers*) con once (11) requisitos mínimos y advertencia destacada para Activos Virtuales con antigüedad inferior a NOVENTA (90) días corridos.\n   - **Artículo 38 (Conservación de la Documentación e Inmutabilidad por 10 Años)**: Preservación íntegra bajo modalidad *Write-Once-Read-Many* (WORM) durante un plazo mínimo de DIEZ (10) años.\n2. **Ley N° 26.831 de Mercado de Capitales (Artículo 2°)**: Delimitación e incompatibilidad técnica automática respecto de Activos Virtuales que constituyan **Valores Negociables** o contratos de inversión, los cuales se encuentran bloqueados a nivel motor de base de datos salvo autorización expresa de Oferta Pública otorgada por la CNV.\n3. **Resolución UIF N° 49/2024**: Régimen de Prevención de Lavado de Activos y Financiación del Terrorismo (PLA/FT/FPADM) para PSAV, incluyendo Perfil Transaccional Dinámico indexado en Salarios Mínimos, Vitales y Móviles (SMVM), monitoreo automatizado y cumplimiento de la Regla de Viaje (*Travel Rule* >= 3 SMVM).\n4. **Comunicaciones Técnicas del BCRA (Marco 2026 para Rieles Fiduciarios y PSPCP)**: Comunicaciones \"A\" 8406 (CIMPRA), \"A\" 8411 (Balance Cero diario con sellado Merkle), \"A\" 8469 (Cuentas Puente de Recaudación Suma Cero), \"A\" 8473 (Gobernanza Anti-Fraude e Interoperabilidad) y Punto 4.1.2 del T.O. de PSPCP (Invariante de Saldo No Negativo).\n\n---\n\n## 2. ESTRUCTURA DEL REGISTRO Y PRESERVACIÓN DE DATOS (ART. 11 PÁRRAFO 1°)\n\n### 2.1. Esquema Relacional del Libro de Órdenes (`public.yohub_orders_book`) y Libro Mayor (`public.yohub_ledger_entries`)\nEl sistema preserva de manera permanente e inalterable la totalidad de las ofertas ingresadas por los clientes y las operaciones liquidadas en dos estructuras relacionales vinculadas atómicamente en PostgreSQL:\n- **`public.yohub_orders_book` (Libro Electrónico de Ofertas y Órdenes — Art. 11)**: Registra el ciclo de vida completo de cada instrucción desde el microsegundo exacto de su recepción (`order_ingested_at`) hasta su ejecución y liquidación (`registered_at`).\n- **`public.yohub_ledger_entries` (Libro Mayor de Partida Doble — Arts. 15, 16 y 20)**: Registra los asientos contables atómicos en planos segregados asociados mediante `transaction_group_id`.\n\nA continuación se detalla el mapeo campo por campo de los **SEIS (6) datos mínimos obligatorios exigidos por el Artículo 11 párrafo 1° de la RG CNV N° 1058/25**:\n\n| N° | Requisito Normativo (Art. 11 párr. 1° RG 1058/25) | Columna en `public.yohub_orders_book` | Columna en `public.yohub_ledger_entries` | Tipo de Dato y Restricción en Motor PostgreSQL |\n| :--- | :--- | :--- | :--- | :--- |\n| **1** | **Fecha, hora, minutos y segundos en que ingresaron como ofertas al sistema** | `order_ingested_at` | `order_ingested_at` | `TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp()` — Capturado en el instante de ingreso de la oferta a la API BFF. |\n| **2** | **Fecha, hora, minutos y segundos en que fueron registradas en el sistema** | `registered_at` | `settled_at` / `created_at` | `TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp()` — Invariante controlada por trigger: `registered_at >= order_ingested_at`. |\n| **3** | **Cantidad ofertada (para compra y/o venta, conversión, transferencia o custodia)** | `offered_amount`, `executed_amount`, `execution_price`, `fee_amount`, `order_type`, `psav_category` | `amount`, `amount_usd`, `fx_rate_usd`, `entry_type` | `NUMERIC(36, 18) NOT NULL` — Cero punto flotante. Categoría PSAV `SMALLINT CHECK (psav_category BETWEEN 1 AND 5)`. |\n| **4** | **Tipo de Activo Virtual (AV)** | `base_asset`, `quote_asset` | `currency` | `VARCHAR NOT NULL` — Validado contra catálogo maestro `public.yohub_products.symbol` (ej. `BTC`, `ETH`, `USDT`, `USDC`, `DAI`, `TRX`, `ARS`, `USD`). |\n| **5** | **Identificador interno o código HASH en caso de haber sido registrada en blockchain** | `order_id` (PK), `transaction_group_id`, `blockchain_tx_hash`, `record_sha256` | `entry_id` (PK), `transaction_group_id`, `account_seq`, `tx_hash`, `prev_hash`, `current_hash` | `UUID v4` para identificadores internos, `BIGINT` monótono para `account_seq`, `TEXT` para `TXID` on-chain y `VARCHAR(64)` para sello SHA-256. |\n| **6** | **Identificación del cliente (Persona Humana o Persona Jurídica)** | `user_id`, `client_tax_id`, `client_person_type` | `account_id -> yohub_accounts.user_id` | `UUID v4 NOT NULL` FK a `public.wallet_users(id)`, `client_tax_id VARCHAR(32)` (CUIT/CUIL/DNI) y `client_person_type VARCHAR(20)` (`'HUMANA'` / `'JURIDICA'`). |\n\n### 2.2. Sincronización Horaria Atómica (Protocolo NTP Estrato 1 y Estándar ISO 8601 UTC-3)\n1. **Fuente de Tiempo Oficial (`ntp_sync_source`)**: Todos los nodos de aplicación y el clúster de base de datos sincronizan su reloj del sistema mediante el protocolo **NTP (Network Time Protocol) Estrato 1** provisto por **AWS Time Sync Service (`169.254.169.123`)**, conectado a una flota de relojes atómicos de Cesio y receptores satelitales GPS redundantes, con desviación máxima controlada inferior a 1 milisegundo (< 1 ms).\n2. **Estampado al Microsegundo en Motor Transaccional**: A diferencia de la función `now()` (que congela el tiempo al inicio del bloque transaccional), los procedimientos almacenados y triggers del Libro de Órdenes y del Libro Mayor invocan **`clock_timestamp()`**, capturando el tiempo real de reloj de pared con resolución de microsegundos.\n3. **Representación y Huso Horario Oficial Argentino**: Los registros se almacenan en tipo `TIMESTAMPTZ` (UTC absoluto con desplazamiento horario) y se exponen en todas las APIs regulatorias, reportes TAD y consolas de auditoría en formato estándar **ISO 8601 (`YYYY-MM-DDTHH:mm:ss.sss-03:00`)** bajo el huso horario oficial de la República Argentina (**`America/Argentina/Buenos_Aires` — UTC-3**).\n4. **Invariante de Prelación Cronológica**: El trigger `trg_immutable_orders_book_art11` verifica en cada inserción o actualización de estado que `NEW.registered_at >= NEW.order_ingested_at`. Cualquier intento de registrar una ejecución con marca temporal anterior al ingreso de la oferta es abortado inmediatamente con la excepción `CHRONOLOGICAL_ORDER_VIOLATION_ART11`.\n\n### 2.3. Precisión Decimal Exacta y Trazabilidad de Identificadores\n1. **Prohibición Absoluta de Punto Flootante**: Queda estrictamente prohibido en toda la arquitectura el uso de tipos `FLOAT`, `REAL`, `DOUBLE PRECISION` en SQL o `parseFloat()` / `Number()` en TypeScript para cálculos monetarios.\n   - **Base de Datos (PostgreSQL)**: Todos los importes (`offered_amount`, `executed_amount`, `execution_price`, `fee_amount`, `amount`, `current_balance`, `locked_balance`) utilizan `NUMERIC(36, 18)`.\n   - **Capa BFF / Servicios (Node.js / TypeScript)**: Toda la aritmética financiera y de conversión se procesa con la librería **`Decimal.js`** configurada con `precision: 36` y redondeo determinista `Decimal.ROUND_DOWN` bajo el contrato de precisión `v2_strict_decimal`.\n   - **Capa Cliente**: Los importes se serializan como cadenas de texto (`string`) o enteros de precisión arbitraria (`BigInt`) expresados en unidades atómicas (*wei*, *satoshis*, centavos).\n2. **Asociación Unívoca con Identificadores Internos y Hashes de Blockchain**:\n   - Cada oferta recibe al ingresar un `order_id` (`UUID v4`) único.\n   - Al ejecutarse contablemente, se vincula de forma inmutable con un `transaction_group_id` (`UUID v4`) que agrupa todas las patas de partida doble en `public.yohub_ledger_entries`.\n   - Cada cuenta afectada incrementa su número de secuencia estrictamente monótono (`account_seq BIGINT`), impidiendo intercalar o reordenar operaciones históricas.\n   - En operaciones con liquidación en redes distribuidas (Categorías 3° y 4°), el campo `blockchain_tx_hash` (en `yohub_orders_book`) y `tx_hash` (en `yohub_ledger_entries`) almacena el identificador criptográfico de la transacción en la blockchain (`TXID` de 64 caracteres hexadecimales), protegido por el índice único `idx_unique_external_deposit_proof_agnostic` para impedir la doble acreditación de un mismo evento on-chain.\n\n### 2.4. Vinculación con el Legajo KYC/KYB del Cliente (Persona Humana y Persona Jurídica)\nNinguna orden puede existir de forma anónima ni disociada de su titular verificado:\n1. Toda fila en `public.yohub_orders_book` posee clave foránea obligatoria (`NOT NULL`) hacia `public.wallet_users(id)` y hacia la entidad PSAV `public.corporates(id)` (`corporate_id`).\n2. Al momento de la inserción, el trigger `fn_immutable_orders_book_art11()` consulta `public.wallet_users` y estampa de forma inmutable en la propia fila de la orden:\n   - `client_tax_id`: El número de **CUIT, CUIL o DNI** del cliente (`COALESCE(wu.cuit_cuil, wu.id_number)`).\n   - `client_person_type`: La clasificación jurídica del titular (`'HUMANA'` o `'JURIDICA'`) tomada de `wallet_users.person_type`.\n3. **Trazabilidad hacia el Legajo Documental Aislado por Sujeto Obligado**:\n   - **Personas Humanas (`client_person_type = 'HUMANA'`)**: El `user_id` enlaza con `public.global_identities`, cuyo atributo `compliance_data -> 'tenant_dossiers' -> [corporate_id]` conserva el legajo de Debida Diligencia del Cliente (biometría facial Didit v3 / Sumsub, prueba de vida, validación RENAPER, declaración jurada PEP, sujeto obligado UIF, residencia fiscal CRS/FATCA y resultado de cribado en listas RePET, ONU y OFAC).\n   - **Personas Jurídicas (`client_person_type = 'JURIDICA'`)**: El registro enlaza adicionalmente con `public.b2b_entities`, donde obran el estatuto social, acta de designación de autoridades, registro de Beneficiarios Finales (>= 10% de participación conforme Res. UIF N° 49/2024), inscripción AFIP/ARCA y poderes de los representantes legales autorizados a operar.\n\n### 2.5. Mecanismos de Inmutabilidad Criptográfica WORM y Conservación por 10 Años (Art. 38)\nPara garantizar que ninguna oferta ingresada ni operación registrada pueda ser alterada, sobrescrita o eliminada física o lógicamente durante el plazo legal mínimo de **DIEZ (10) años** (Art. 38 RG CNV N° 1058/25), la base de datos implementa tres anillos de defensa criptográfica a nivel de motor PostgreSQL:\n1. **Trigger WORM en el Libro de Órdenes (`trg_immutable_orders_book_art11`)**:\n   - Intercepta cualquier sentencia `DELETE` sobre `public.yohub_orders_book` y aborta la transacción arrojando la excepción `ART11_RG1058_DELETE_FORBIDDEN`.\n   - Intercepta cualquier sentencia `UPDATE` que intente modificar los atributos originales de la oferta (`order_id`, `corporate_id`, `user_id`, `order_type`, `psav_category`, `base_asset`, `quote_asset`, `offered_amount`, `order_ingested_at`, `client_tax_id`, `client_person_type`), abortando la transacción con `ART11_RG1058_IMMUTABILITY_VIOLATION`. Únicamente se permite la transición controlada de `status`, `executed_amount`, `registered_at`, `transaction_group_id` y `blockchain_tx_hash` cuando una orden en tránsito pasa a estado final liquidado.\n   - Calcula y sella en la columna `record_sha256` el digest criptográfico `SHA-256` (`extensions.digest(..., 'sha256')`) sobre la concatenación canónica de todos los atributos de la orden.\n2. **Trigger WORM y Cadena de Bloques Interna en el Libro Mayor (`trg_immutable_ledger_entries`)**:\n   - Prohíbe en forma absoluta cualquier `UPDATE` o `DELETE` sobre `public.yohub_ledger_entries`. Cualquier ajuste contable o reversa debe instrumentarse exclusivamente mediante un nuevo asiento compensatorio de partida doble (`CLEARING_ADJUSTMENT` o `REVERSAL`) vinculado al asiento original mediante `parent_entry_id` y `root_transaction_group_id`.\n   - Cada asiento incorpora en su cálculo de `current_hash` (`SHA-256`) el hash exacto del asiento inmediato anterior de la misma cuenta (`prev_hash`), formando una estructura encadenada donde la alteración de un solo bit histórico invalidaría toda la cadena subsiguiente.\n3. **Sellado Diario de Árbol de Merkle (`public.bcra_daily_ledger_seals`)**:\n   - Al cierre de cada jornada operativa, el motor consolida los hashes de todas las operaciones y saldos de Cuentas de Orden en una Raíz de Merkle (`merkle_root_hash` SHA-256), la cual queda asentada y disponible para verificación pública en `/api/cnv/proof-of-reserves` y `/cnv-transparencia`.\n\n---\n\n## 3. PROCEDIMIENTOS TÉCNICOS DE TRATAMIENTO DE ÓRDENES POR CATEGORÍA (ART. 11 PÁRRAFO 2° — CATEGORÍAS 1° A 5°)\n\nDe conformidad con el segundo párrafo del Artículo 11 de la RG CNV N° 1058/25 y el Artículo 4° bis de la Ley N° 25.246, se detallan a continuación los procedimientos técnicos de procesamiento para cada una de las cinco (5) categorías operativas:\n\n### 3.1. Categoría 1°: Intercambio entre Activos Virtuales y Monedas de Curso Legal (Monedas Fiduciarias ARS / USD)\nComprende las órdenes de compra (`order_type = 'BUY'`, `psav_category = 1`) y venta (`order_type = 'SELL'`, `psav_category = 1`) de Activos Virtuales contra Pesos Argentinos (`ARS`) o Dólares Estadounidenses (`USD`):\n1. **Ingreso y Conciliación de Fondos Fiduciarios (In-Ramp Bancario)**:\n   - El cliente transfiere fondos desde una cuenta bancaria o de pago de su propia titularidad hacia la cuenta recaudadora de **Cuentas de Orden** del PSAV abierta en la Entidad Financiera Patrocinadora (**Banco Coinag S.A. APIs v4.9 / Banco CMF / Red COELSA**), operando bajo el esquema de salto transaccional de **CVU Corta a CBU Larga Recaudadora** exenta del Impuesto sobre los Créditos y Débitos Bancarios conforme al **Decreto PEN N° 475/2026 y RG ARCA N° 5869/2026**.\n   - El webhook bancario autenticado (`/api/webhooks/sponsor-bank/transferencia`) verifica la regla de **Misma Titularidad (*Same-Name Rule* — BCRA Com. \"A\" 7340 y Art. 18 RG CNV 1058/25)** cotejando el CUIT/CUIL del originante informado por COELSA contra el `cuit_cuil` del legajo del usuario en `public.wallet_users`. Si los CUIT/CUIL no coinciden o provienen de terceros no autorizados, el depósito es rechazado o retenido preventivamente.\n   - El sistema almacena la evidencia forense del movimiento bancario (incluyendo la trama cruda de 180 caracteres en `public.bank_clearing_items.raw_line` durante la conciliación SFTP D-1 de lotes COELSA DEBIN Fase 4 v5.0 y Movimientos PSP 1.1) y acredita el saldo fiduciario en la cuenta `MEMORANDUM_CLIENT` del usuario.\n2. **Ingreso de la Oferta de Compra/Venta y Reserva de Saldo**:\n   - Cuando el cliente instruye la compra (`ARS -> USDT`) o venta (`USDT -> ARS`), el sistema registra la oferta en `public.yohub_orders_book` con `psav_category = 1` y `order_ingested_at = clock_timestamp()`.\n   - Se bloquea pesimistamente la cuenta de origen (`SELECT ... FOR UPDATE`) y se transfiere el monto ofertado de `current_balance` a `locked_balance`.\n3. **Calce contra Proveedor de Liquidez y Liquidación en Partida Doble**:\n   - La orden se ejecuta contra el libro interno o se rutea hacia el proveedor de liquidez institucional regulado (`Bit2Me` — convenio registrado bajo el Art. 35 RG CNV 1058/25 en `public.bcra_third_party_registry`) mediante el patrón *Transactional Outbox*.\n   - Confirmado el calce, dentro de una única transacción atómica PostgreSQL se consume el `locked_balance`, se asientan las partidas de débito y crédito en `public.yohub_ledger_entries` (verificando Suma Cero = 0 en el `transaction_group_id`), y se sella `registered_at = clock_timestamp()` y `record_sha256` en `public.yohub_orders_book`.\n4. **Egreso Fiduciario (Off-Ramp Bancario)**:\n   - En órdenes de venta con retiro fiduciario hacia CBU/CVU externo, el sistema valida previamente la titularidad de la cuenta destino en COELSA y liquida la transferencia inmediata registrando el identificador COELSA/OBID en el asiento contable.\n\n### 3.2. Categoría 2°: Intercambio entre Una o Más Formas de Activos Virtuales (Swap Cripto-a-Cripto)\nComprende las órdenes de conversión directa entre distintos Activos Virtuales (`order_type = 'SWAP'`, `psav_category = 2`, ej. `BTC <-> USDT`, `ETH <-> USDC`):\n1. **Fijación de Cotización Firme y *Quote Locking* Criptográfico (Art. 31)**:\n   - Previo a la confirmación del cliente, el motor de cotizaciones (`/api/wallet/transfer/quote` y `/api/wallet/swap-internal`) consulta el precio en tiempo real del Oráculo institucional y aplica de forma transparente el diferencial (*spread*) máximo parametrizado para el Tenant en `public.corporate_cnv_psav_configs.fee_crypto_swap_max_spread_bps` (Art. 31 RG CNV 1058/25).\n   - El servidor emite un token de cotización firmado con **HMAC-SHA256** que incluye el par (`base_asset`, `quote_asset`), la tasa exacta (`execution_price`), la comisión desglosada (`fee_amount`) y un tiempo de expiración determinista (TTL).\n2. **Prioridad Temporal Estricta FIFO (*First-In, First-Out*) Anti-Front-Running (Arts. 24 inc. e y 26)**:\n   - Las órdenes ingresadas se procesan en estricto orden cronológico de recepción según su marca temporal `order_ingested_at` y su secuencia monótona.\n   - La plataforma no realiza operaciones de *proprietary trading* con ventaja informativa ni reordena colas de ejecución, garantizando neutralidad absoluta y ausencia de *front-running*.\n3. **Asiento Contable Atómico Multi-Pata**:\n   - La función transaccional ejecuta en una sola unidad de trabajo (`BEGIN ... COMMIT`):\n     - Débito del activo entregado (`SWAP_DEBIT`) en la cuenta `MEMORANDUM_CLIENT` del usuario;\n     - Crédito del activo recibido (`SWAP_CREDIT`) en la cuenta `MEMORANDUM_CLIENT` del usuario;\n     - Contrapartida simétrica en las cuentas ómnibus segregadas (`OMNIBUS_MASTER`) de ambos activos;\n     - Imputación de la comisión devengada en la cuenta de resultados del PSAV (`REVENUE_FEE` en el plano `PATRIMONIAL_OWN`).\n   - Se registra la orden en `public.yohub_orders_book` con `psav_category = 2`, `status = 'EXECUTED'` y sello `record_sha256`.\n\n### 3.3. Categoría 3°: Transferencia de Activos Virtuales\nComprende toda instrucción de envío o recepción de Activos Virtuales (`order_type = 'TRANSFER'`, `psav_category = 3`), distinguiendo técnicamente dos modalidades:\n1. **Transferencias Internas entre Clientes en el Libro Mayor (*Off-Chain Book-Entry*)**:\n   - Cuando el destinatario es otro usuario registrado en la infraestructura (`INTERNAL_TRANSFER` o `CROSS_TENANT_TRANSFER`), la liquidación se realiza íntegramente dentro de PostgreSQL mediante la función `rpc_execute_federated_transfer`.\n   - No se incurre en costo de gas de red blockchain (comisión `0.00%` bonificada según Cuadro Tarifario Art. 31), la acreditación es instantánea (sub-segundo) y el movimiento queda asentado simultáneamente en `public.yohub_orders_book` (`psav_category = 3`) y en `public.yohub_ledger_entries`.\n2. **Transferencias Externas hacia o desde Direcciones en la Blockchain (*On-Chain Transfers*)**:\n   - **Cumplimiento Automatizado de la Regla de Viaje (*Travel Rule* — Art. 26 Res. UIF N° 49/2024)**: En toda transferencia cuyo importe en dólares estadounidenses iguale o supere el equivalente a **TRES (3) Salarios Mínimos, Vitales y Móviles (`3 * SMVM`)** —o el umbral paramétrico inferior configurado en `public.yohub_regulatory_parameters`—, el motor exige y persiste en `public.travel_rule_records` los datos completos del originante (`originator_name`, `originator_id_number`), del beneficiario (`beneficiary_name`, `beneficiary_type`), el PSAV/VASP de destino (`beneficiary_vasp_name`), la dirección de billetera (`destination_wallet_address`) y la declaración jurada de titularidad en caso de billeteras auto-custodiadas (*unhosted wallets*, `unhosted_ownership_declared`).\n   - **Compuerta de Lista Blanca Obligatoria con Enfriamiento de 24 Horas (Art. 17 inc. d RG CNV 1058/25)**: Ningún retiro on-chain puede ejecutarse hacia una dirección externa que no se encuentre previamente registrada y verificada en `public.yohub_whitelisted_addresses` para ese `user_id` y `corporate_id`, habiendo transcurrido el período de enfriamiento (*cooldown*) mínimo de **VEINTICUATRO (24) horas** parametrizado en `corporate_cnv_psav_configs.whitelist_cooldown_hours`.\n   - **Paridad Custodial vs. Non-Custodial (Smart Accounts ERC-4337)**: En billeteras de abstracción de cuenta (ERC-4337), el sistema verifica criptográficamente el recibo de ejecución y el `tx_hash` real en el nodo RPC antes de impactar el espejo contable.\n\n### 3.4. Categoría 4°: Custodia y/o Administración de Activos Virtuales\nComprende el resguardo técnico, administración de claves criptográficas, detección de depósitos on-chain (`order_type = 'CUSTODY_DEPOSIT'`, `psav_category = 4`), procesamiento de retiros (`order_type = 'CUSTODY_WITHDRAWAL'`, `psav_category = 4`) y conciliación de reservas:\n1. **Procedimiento Técnico de Detección y Acreditación de Depósitos On-Chain**:\n   - Los servicios de indexación y webhooks autenticados (`/api/webhooks/gateway/[provider]` con validación de firma criptográfica HMAC-SHA512 y control de repetición *anti-replay*) monitorean las direcciones de depósito asignadas.\n   - Para prevenir ataques de reorganización de cadena (*chain reorgs*) o doble gasto, el sistema exige alcanzar el número mínimo de confirmaciones definitivas antes de cambiar el estado a acreditado:\n     - **Red Polygon PoS**: mínimo **64 bloques** confirmados;\n     - **Red Bitcoin Mainnet**: mínimo **3 bloques** minados;\n     - **Red Ethereum Mainnet**: estado de finalidad PoS (**Finalized Checkpoint** >= 2 épocas / 64 slots);\n     - **Red TRON Mainnet (TRC-20)**: mínimo **19 bloques Solidified** confirmados por Super Representantes;\n     - **Redes Ethereum L2 (Arbitrum / Optimism / Base)**: confirmación de lote publicado en L1 (*L1 Batch Finality*).\n   - **Blindaje Anti-Emisión Ficticia (*Agnostic Proof of Deposit Invariant*)**: El trigger de base de datos valida que todo asiento `EXTERNAL_DEPOSIT` posea su prueba criptográfica de depósito verificada (`tx_hash` on-chain o referencia de cámara COELSA); cualquier intento de inyectar saldo sin respaldo arroja la excepción `UNBACKED_DEPOSIT_REJECTED`. Asimismo, el índice único `idx_unique_external_deposit_proof_agnostic` garantiza idempotencia absoluta.\n2. **Política de Custodia Térmica y Segregación en Cuentas de Orden (Arts. 14, 15, 16 y 17)**:\n   - Todos los activos de clientes se contabilizan en el plano `MEMORANDUM_CLIENT`, separados del plano `PATRIMONIAL_OWN`.\n   - La distribución física de los activos en custodia respeta la relación paramétrica auditada en `public.corporate_cnv_psav_configs`:\n     - **Bóveda Fría (*Cold Vault* — HSM / Air-Gapped / MPC)**: mínimo **70%** (`cold_vault_min_pct >= 70`);\n     - **Billetera Tibia (*Warm Wallet*)**: máximo **20%** (`warm_wallet_max_pct <= 20`);\n     - **Billetera Caliente (*Hot Wallet* transaccional)**: máximo **10%** (`hot_wallet_max_pct <= 10`);\n     - Con validación estricta Hot + Warm + Cold = 100%.\n3. **Gobernanza Multifirma por Umbral (Art. 17 inc. c) y Emisión de Retiros vía HSM/MPC**:\n   - Todo retiro o movimiento de tesorería desde custodia cuyo valor equivalente iguale o supere el umbral de seguridad parametrizado (**USD 10.000,00** en `multisig_cold_threshold_usd`) requiere obligatoriamente esquema de firma mancomunada **2-de-3 (`2_OF_3`)** registrado en `public.yohub_multisig_approvals`, con intervención de al menos dos oficiales autorizados bajo Principio de Control Dual (4 Ojos) y autenticación biométrica FIDO2/WebAuthn Level 3 antes de que el módulo HSM/MPC transmita la transacción a la red.\n\n### 3.5. Categoría 5°: Servicios Financieros Relacionados con la Oferta de un Emisor y/o Venta de un Activo Virtual (Colocación Primaria)\nComprende la participación y prestación de servicios financieros vinculados a la emisión o colocación primaria de un Activo Virtual (`order_type = 'PRIMARY_ISSUANCE'`, `psav_category = 5`):\n1. **Debida Diligencia Reforzada del Emisor y Segregación por Emisión**:\n   - Previo a habilitar cualquier proyecto en Categoría 5°, el Comité de Cumplimiento ejecuta la debida diligencia reforzada (KYB, Beneficiarios Finales, auditoría técnica del contrato inteligente y dictamen legal sobre la naturaleza jurídica del token) y requiere aprobación expresa por Acta de Directorio conforme a `category_5_primary_issuance_policy`.\n2. **Validación Previa Obligatoria del Whitepaper Oficial (Art. 37 RG CNV 1058/25)**:\n   - El activo debe encontrarse dado de alta en `public.yohub_products` cumpliendo los once (11) recaudos informativos del Artículo 37: identificación del emisor (`issuer_info`), resumen de riesgos técnicos y económicos (`art37_risk_summary`), fecha de lanzamiento (`launch_date`), enlace público permanente al documento técnico fundacional (`whitepaper_url`) y sello criptográfico de integridad de 64 caracteres hexadecimales (`whitepaper_sha256`).\n   - Cuando la antigüedad del Activo Virtual desde su `launch_date` sea inferior a **NOVENTA (90) días corridos** (`is_under_90_days = true`), la plataforma lo exhibe en una sección segregada con advertencia de riesgo reforzada conforme al último párrafo del Artículo 36.\n   - El trigger `trg_enforce_cat5_security_gate` en `public.yohub_products` y el trigger `trg_immutable_orders_book_art11` en `public.yohub_orders_book` rechazan con la excepción `CAT5_WHITEPAPER_REQUIRED_ART37` cualquier intento de activar un activo o cursar una orden `PRIMARY_ISSUANCE` si `whitepaper_url` o `whitepaper_sha256` (64 chars hex) se encuentran vacíos o incompletos.\n3. **Bloqueo Técnico Determinista de Valores Negociables sin Oferta Pública CNV (Ley N° 26.831 Art. 2)**:\n   - El catálogo de productos incluye el atributo booleano `is_negotiable_security`, el indicador `cnv_public_offering_authorized` y el campo `cnv_offering_resolution`.\n   - Si un activo representa un derecho de crédito, participación societaria, instrumento de deuda soberana/corporativa o contrato de inversión alcanzado por el **Artículo 2° de la Ley N° 26.831** (por ejemplo, el activo `TBILL_RWA` — *Tokenized US T-Bill RWA*, marcado con `is_negotiable_security = true`), **queda bloqueado determinísticamente a nivel de motor de base de datos PostgreSQL** (`is_active = false`, `cat5_primary_issuance_enabled = false`).\n   - El trigger `trg_enforce_cat5_security_gate` impide activar (`is_active = true`) o habilitar la colocación primaria (`cat5_primary_issuance_enabled = true`), y el trigger `trg_immutable_orders_book_art11` impide insertar órdenes sobre dicho activo mientras `cnv_public_offering_authorized` sea `false` o carezca de número de Resolución de Oferta Pública de la CNV (`cnv_offering_resolution`), arrojando de forma inmediata el error `SECURITY_TOKEN_REQUIRES_CNV_PUBLIC_OFFERING_AUTH`.\n\n---\n\n## 4. VALIDACIONES PRE-TRANSACCIONALES Y CONTROL DE CONCURRENCIA\n\n### 4.1. Las Seis (6) Validaciones Automáticas Pre-Transaccionales Síncronas\nNinguna oferta ingresada al sistema puede pasar a ejecución sin superar de manera síncrona y satisfactoria las siguientes seis (6) compuertas automáticas:\n1. **Compuerta 1 — Estado del Legajo KYC/KYB y Listas Restrictivas PLA/FT**: Verificación en `public.wallet_users` y `global_identities.compliance_data.tenant_dossiers[corporate_id]` de que el cliente posee estado `APPROVED` / `VERIFIED_ALL`, sin bloqueos preventivos ni alertas críticas abiertas en `public.compliance_alerts` (RePET, ONU, OFAC, GAFI).\n2. **Compuerta 2 — Aceptación Expresa de la DDJJ de Riesgos (Art. 36) y Términos de Cuentas de Orden (Art. 16)**: Verificación en `public.corporate_legal_acceptances` de que el usuario ha firmado digitalmente la versión vigente de `DDJJ_RIESGOS_ART36` (incisos `a` a `l`) y `TNC_CUENTAS_DE_ORDEN_ART16_18_19`.\n3. **Compuerta 3 — Evaluación del Perfil Transaccional Dinámico Indexado en SMVM (Res. UIF N° 49/2024)**: Invocación a la función PL/pgSQL `public.rpc_evaluate_transactional_profile`, que calcula el monto de la orden en USD y valida que no exceda:\n   - El tope máximo por transacción (`max_per_tx_usd`);\n   - El acumulado móvil de las últimas **24 horas** (`max_daily_usd`);\n   - El acumulado móvil de los últimos **30 días** (`max_monthly_usd` / multiplicador SMVM mensual);\n   - El acumulado móvil de los últimos **365 días** (`max_annual_usd` / multiplicador SMVM anual).\n4. **Compuerta 4 — Disponibilidad de Saldo Libre de Bloqueos e Invariante de Saldo No Negativo (BCRA PSPCP 4.1.2)**: Verificación matemática en precisión `NUMERIC(36, 18)` de que la cuenta de origen posee saldo disponible suficiente (`current_balance - locked_balance >= offered_amount + fee_amount`). El motor tiene prohibido otorgar descubiertos o permitir saldos negativos (`CHECK (current_balance >= 0 AND locked_balance >= 0)`).\n5. **Compuerta 5 — Reglas de Producto, Red, Travel Rule y Whitelist 24h**: Verificación de que el activo permite la dirección del flujo (`default_allow_inbound` / `default_allow_outbound`), que en retiros on-chain la dirección destino cumple las 24 horas de enfriamiento en `yohub_whitelisted_addresses` (Art. 17 inc. d) y que se ha integrado el registro de `travel_rule_records` si el monto es >= 3 SMVM.\n6. **Compuerta 6 — Compuerta de Categoría 5°, Whitepaper Art. 37 e Incompatibilidad Ley 26.831**: Verificación por los triggers `trg_enforce_cat5_security_gate` y `trg_immutable_orders_book_art11` de que el activo posee `whitepaper_sha256` válido y no constituye un Valor Negociable sin autorización de oferta pública de la CNV.\n\n### 4.2. Mecanismo de Bloqueo Transaccional Pesimista y Control de Concurrencia\nPara garantizar atomicidad (`ACID`), aislamiento serializable efectivo sobre saldos y ausencia total de condiciones de carrera (*race conditions*) o interbloqueos (*deadlocks*) bajo alta concurrencia:\n1. **Bloqueo Pesimista con Ordenamiento Lexicográfico Determinista Anti-Deadlock**:\n   - Cuando una operación involucra dos o más cuentas contables (ej. cuenta origen del cliente, cuenta destino, cuenta ómnibus y cuenta de comisiones), el procedimiento almacenado adquiere el bloqueo exclusivo de fila ejecutando:\n     ```sql\n     SELECT id, current_balance, locked_balance\n     FROM public.yohub_accounts\n     WHERE id = ANY(v_account_ids)\n     ORDER BY id ASC\n     FOR UPDATE;\n     ```\n   - Al ordenar los identificadores `UUID` en forma ascendente (`ORDER BY id ASC`) antes de adquirir los cerrojos `FOR UPDATE`, dos transacciones concurrentes cruzadas (ej. Usuario A transfiere a Usuario B al mismo milisegundo en que Usuario B transfiere a Usuario A) solicitan los bloqueos exactamente en el mismo orden canónico, **eliminando matemáticamente la posibilidad de un ciclo de espera (*deadlock*)**.\n2. **Reserva Atómica de Saldo en Tránsito (`locked_balance` — Saga Fase 1)**:\n   - En operaciones asíncronas que dependen de confirmación externa (liquidación en blockchain o cámara compensadora bancaria), la Fase 1 deduce el importe de `current_balance` o lo compromete en `locked_balance` dentro de la misma transacción en que la orden ingresa a `yohub_orders_book` (`status = 'PENDING_SETTLEMENT'`). Si el cliente envía múltiples peticiones simultáneas (*double-click* o ataque de concurrencia), la segunda petición encuentra el cerrojo `FOR UPDATE` y, al liberarse, verifica el saldo ya disminuido, siendo rechazada de inmediato por saldo insuficiente.\n3. **Secuencia Monótona por Cuenta (`account_seq`) e Invariante Diferida de Suma Cero**:\n   - Cada inserción en `public.yohub_ledger_entries` asigna `account_seq = COALESCE(MAX(account_seq), 0) + 1` bajo el cerrojo de la cuenta.\n   - Al finalizar la transacción (`DEFERRABLE INITIALLY DEFERRED`), el constraint trigger `fn_enforce_zero_sum_transaction_group` comprueba que la suma algebraica de todos los movimientos del `transaction_group_id` por moneda sea exactamente igual a cero (`SUM(amount) = 0.000000000000000000`). En caso de discrepancia de siquiera 1e-18 unidades, la transacción completa hace `ROLLBACK` automático.\n","sha256_hash":"SHA256:91C0F09147D851D6511F6F7565029834D8035921181EBA23AECD09A813B0DA86","board_approval_act":"Acta de Directorio PSAV 2026 — Aprobación Manual Técnico M01 (Art. 11 RG CNV N° 1058/25)","effective_from":"2026-10-16T21:40:40.204697+00:00","is_active":true},{"id":"c5f5e34e-0149-4404-b3b9-06af290e58c2","corporate_id":"da700000-0000-4000-8000-000000000001","doc_type":"M01_MANUAL_SISTEMAS_ORDENES_ART11","version_tag":"v2.0-CNV1058-M01","title":"Manual de Procedimientos de Sistemas Informáticos, Tratamiento de Órdenes y Registro Cronológico al Segundo (Art. 11 RG CNV N° 1058/25)","normative_reference":"RG CNV N° 1058/25","summary_markdown":"# MANUAL DE PROCEDIMIENTOS DE SISTEMAS INFORMÁTICOS, TRATAMIENTO DE ÓRDENES Y REGISTRO CRONOLÓGICO AL SEGUNDO (M01)\n## RESOLUCIÓN GENERAL CNV N° 1058/2025 — ARTÍCULO 11 | LEY N° 27.739 | RESOLUCIÓN UIF N° 49/2024\n\n- **Código de Documento**: `M01_MANUAL_SISTEMAS_ORDENES_ART11`\n- **Versión Vigente**: `v2.0-CNV1058-M01` (Producción — Homologación Técnica Área de Sistemas CNV)\n- **Entidad Sujeto Obligado / PSAV**: Configurada por Tenant en `public.corporate_cnv_psav_configs` (incluyendo **DAV NEXT S.A.** — CUIT `30-71960008-1`)\n- **Órgano de Aprobación**: Directorio de la Sociedad — Acta de Directorio Fundacional PSAV 2026\n- **Responsables de Emisión y Control**: Responsable de Cumplimiento Regulatorio y Control Interno (Art. 21 RG CNV N° 1058/25), Oficial de Cumplimiento PLA/FT (Res. UIF N° 49/2024) y Dirección de Tecnología (CTO / Idóneo Informático Art. 20)\n\n---\n\n## 1. ENCUADRE NORMATIVO Y ALCANCE INSTITUCIONAL\n\nEl presente Manual de Procedimientos de Sistemas Informáticos, Tratamiento de Órdenes y Registro Cronológico al Segundo (en adelante, el **\"Manual M01\"**) establece la arquitectura técnica, las estructuras de datos inmutables, los algoritmos de sincronización horaria, los flujos transaccionales para las **Categorías 1° a 5° de Proveedores de Servicios de Activos Virtuales (PSAV)** y los mecanismos de control de concurrencia implementados en producción en el motor transaccional (**Ledger SSOT V5**).\n\nEl diseño e implementación técnica dan cumplimiento estricto y verificable al siguiente plexo normativo de la República Argentina:\n1. **Resolución General CNV N° 1058/2025 (Título XIV, Capítulo III de las Normas de la Comisión Nacional de Valores — T.O. 2013 y mod.)**:\n   - **Artículo 4° y Artículo 4° bis de la Ley N° 25.246 (mod. por Ley N° 27.739)**: Definición y alcance de las Cinco (5) Categorías de servicios sobre Activos Virtuales.\n   - **Artículo 11 (Sistemas Informáticos y Registro Cronológico al Segundo)**: Obligación de contar con sistemas informáticos que permitan registrar en forma cronológica, al segundo y con carácter inalterable, cada oferta ingresada y cada operación registrada con sus seis (6) atributos mínimos obligatorios, así como los procedimientos técnicos aplicables a cada categoría operativa.\n   - **Artículos 14, 15, 16, 17, 18 y 19 (Segregación Patrimonial en Cuentas de Orden, Prueba de Reservas y Custodia)**: Aislamiento matemático entre el patrimonio propio del PSAV (`PATRIMONIAL_OWN`) y los fondos/activos de terceros (`MEMORANDUM_CLIENT`), conciliación 1:1, custodia multifirma y prohibición de disposición de activos de clientes sin consentimiento expreso.\n   - **Artículo 20 (Auditoría Anual de Sistemas Informáticos)**: Trazabilidad criptográfica SHA-256 auditable por profesional independiente con competencia técnica.\n   - **Artículos 24 inc. e), 26 y 31 (Prioridad Temporal FIFO, Prevención de Front-Running y Transparencia Tarifaria)**: Ejecución estricta por orden de prelación temporal y divulgación previa de comisiones y spreads.\n   - **Artículos 36 y 37 (Divulgación de Riesgos al Consumidor y Régimen de Whitepapers)**: Exigencia de aceptación previa de los 12 riesgos regulatorios (incisos `a` a `l`), publicación de fichas técnicas oficiales (*Whitepapers*) con once (11) requisitos mínimos y advertencia destacada para Activos Virtuales con antigüedad inferior a NOVENTA (90) días corridos.\n   - **Artículo 38 (Conservación de la Documentación e Inmutabilidad por 10 Años)**: Preservación íntegra bajo modalidad *Write-Once-Read-Many* (WORM) durante un plazo mínimo de DIEZ (10) años.\n2. **Ley N° 26.831 de Mercado de Capitales (Artículo 2°)**: Delimitación e incompatibilidad técnica automática respecto de Activos Virtuales que constituyan **Valores Negociables** o contratos de inversión, los cuales se encuentran bloqueados a nivel motor de base de datos salvo autorización expresa de Oferta Pública otorgada por la CNV.\n3. **Resolución UIF N° 49/2024**: Régimen de Prevención de Lavado de Activos y Financiación del Terrorismo (PLA/FT/FPADM) para PSAV, incluyendo Perfil Transaccional Dinámico indexado en Salarios Mínimos, Vitales y Móviles (SMVM), monitoreo automatizado y cumplimiento de la Regla de Viaje (*Travel Rule* >= 3 SMVM).\n4. **Comunicaciones Técnicas del BCRA (Marco 2026 para Rieles Fiduciarios y PSPCP)**: Comunicaciones \"A\" 8406 (CIMPRA), \"A\" 8411 (Balance Cero diario con sellado Merkle), \"A\" 8469 (Cuentas Puente de Recaudación Suma Cero), \"A\" 8473 (Gobernanza Anti-Fraude e Interoperabilidad) y Punto 4.1.2 del T.O. de PSPCP (Invariante de Saldo No Negativo).\n\n---\n\n## 2. ESTRUCTURA DEL REGISTRO Y PRESERVACIÓN DE DATOS (ART. 11 PÁRRAFO 1°)\n\n### 2.1. Esquema Relacional del Libro de Órdenes (`public.yohub_orders_book`) y Libro Mayor (`public.yohub_ledger_entries`)\nEl sistema preserva de manera permanente e inalterable la totalidad de las ofertas ingresadas por los clientes y las operaciones liquidadas en dos estructuras relacionales vinculadas atómicamente en PostgreSQL:\n- **`public.yohub_orders_book` (Libro Electrónico de Ofertas y Órdenes — Art. 11)**: Registra el ciclo de vida completo de cada instrucción desde el microsegundo exacto de su recepción (`order_ingested_at`) hasta su ejecución y liquidación (`registered_at`).\n- **`public.yohub_ledger_entries` (Libro Mayor de Partida Doble — Arts. 15, 16 y 20)**: Registra los asientos contables atómicos en planos segregados asociados mediante `transaction_group_id`.\n\nA continuación se detalla el mapeo campo por campo de los **SEIS (6) datos mínimos obligatorios exigidos por el Artículo 11 párrafo 1° de la RG CNV N° 1058/25**:\n\n| N° | Requisito Normativo (Art. 11 párr. 1° RG 1058/25) | Columna en `public.yohub_orders_book` | Columna en `public.yohub_ledger_entries` | Tipo de Dato y Restricción en Motor PostgreSQL |\n| :--- | :--- | :--- | :--- | :--- |\n| **1** | **Fecha, hora, minutos y segundos en que ingresaron como ofertas al sistema** | `order_ingested_at` | `order_ingested_at` | `TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp()` — Capturado en el instante de ingreso de la oferta a la API BFF. |\n| **2** | **Fecha, hora, minutos y segundos en que fueron registradas en el sistema** | `registered_at` | `settled_at` / `created_at` | `TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp()` — Invariante controlada por trigger: `registered_at >= order_ingested_at`. |\n| **3** | **Cantidad ofertada (para compra y/o venta, conversión, transferencia o custodia)** | `offered_amount`, `executed_amount`, `execution_price`, `fee_amount`, `order_type`, `psav_category` | `amount`, `amount_usd`, `fx_rate_usd`, `entry_type` | `NUMERIC(36, 18) NOT NULL` — Cero punto flotante. Categoría PSAV `SMALLINT CHECK (psav_category BETWEEN 1 AND 5)`. |\n| **4** | **Tipo de Activo Virtual (AV)** | `base_asset`, `quote_asset` | `currency` | `VARCHAR NOT NULL` — Validado contra catálogo maestro `public.yohub_products.symbol` (ej. `BTC`, `ETH`, `USDT`, `USDC`, `DAI`, `TRX`, `ARS`, `USD`). |\n| **5** | **Identificador interno o código HASH en caso de haber sido registrada en blockchain** | `order_id` (PK), `transaction_group_id`, `blockchain_tx_hash`, `record_sha256` | `entry_id` (PK), `transaction_group_id`, `account_seq`, `tx_hash`, `prev_hash`, `current_hash` | `UUID v4` para identificadores internos, `BIGINT` monótono para `account_seq`, `TEXT` para `TXID` on-chain y `VARCHAR(64)` para sello SHA-256. |\n| **6** | **Identificación del cliente (Persona Humana o Persona Jurídica)** | `user_id`, `client_tax_id`, `client_person_type` | `account_id -> yohub_accounts.user_id` | `UUID v4 NOT NULL` FK a `public.wallet_users(id)`, `client_tax_id VARCHAR(32)` (CUIT/CUIL/DNI) y `client_person_type VARCHAR(20)` (`'HUMANA'` / `'JURIDICA'`). |\n\n### 2.2. Sincronización Horaria Atómica (Protocolo NTP Estrato 1 y Estándar ISO 8601 UTC-3)\n1. **Fuente de Tiempo Oficial (`ntp_sync_source`)**: Todos los nodos de aplicación y el clúster de base de datos sincronizan su reloj del sistema mediante el protocolo **NTP (Network Time Protocol) Estrato 1** provisto por **AWS Time Sync Service (`169.254.169.123`)**, conectado a una flota de relojes atómicos de Cesio y receptores satelitales GPS redundantes, con desviación máxima controlada inferior a 1 milisegundo (< 1 ms).\n2. **Estampado al Microsegundo en Motor Transaccional**: A diferencia de la función `now()` (que congela el tiempo al inicio del bloque transaccional), los procedimientos almacenados y triggers del Libro de Órdenes y del Libro Mayor invocan **`clock_timestamp()`**, capturando el tiempo real de reloj de pared con resolución de microsegundos.\n3. **Representación y Huso Horario Oficial Argentino**: Los registros se almacenan en tipo `TIMESTAMPTZ` (UTC absoluto con desplazamiento horario) y se exponen en todas las APIs regulatorias, reportes TAD y consolas de auditoría en formato estándar **ISO 8601 (`YYYY-MM-DDTHH:mm:ss.sss-03:00`)** bajo el huso horario oficial de la República Argentina (**`America/Argentina/Buenos_Aires` — UTC-3**).\n4. **Invariante de Prelación Cronológica**: El trigger `trg_immutable_orders_book_art11` verifica en cada inserción o actualización de estado que `NEW.registered_at >= NEW.order_ingested_at`. Cualquier intento de registrar una ejecución con marca temporal anterior al ingreso de la oferta es abortado inmediatamente con la excepción `CHRONOLOGICAL_ORDER_VIOLATION_ART11`.\n\n### 2.3. Precisión Decimal Exacta y Trazabilidad de Identificadores\n1. **Prohibición Absoluta de Punto Flootante**: Queda estrictamente prohibido en toda la arquitectura el uso de tipos `FLOAT`, `REAL`, `DOUBLE PRECISION` en SQL o `parseFloat()` / `Number()` en TypeScript para cálculos monetarios.\n   - **Base de Datos (PostgreSQL)**: Todos los importes (`offered_amount`, `executed_amount`, `execution_price`, `fee_amount`, `amount`, `current_balance`, `locked_balance`) utilizan `NUMERIC(36, 18)`.\n   - **Capa BFF / Servicios (Node.js / TypeScript)**: Toda la aritmética financiera y de conversión se procesa con la librería **`Decimal.js`** configurada con `precision: 36` y redondeo determinista `Decimal.ROUND_DOWN` bajo el contrato de precisión `v2_strict_decimal`.\n   - **Capa Cliente**: Los importes se serializan como cadenas de texto (`string`) o enteros de precisión arbitraria (`BigInt`) expresados en unidades atómicas (*wei*, *satoshis*, centavos).\n2. **Asociación Unívoca con Identificadores Internos y Hashes de Blockchain**:\n   - Cada oferta recibe al ingresar un `order_id` (`UUID v4`) único.\n   - Al ejecutarse contablemente, se vincula de forma inmutable con un `transaction_group_id` (`UUID v4`) que agrupa todas las patas de partida doble en `public.yohub_ledger_entries`.\n   - Cada cuenta afectada incrementa su número de secuencia estrictamente monótono (`account_seq BIGINT`), impidiendo intercalar o reordenar operaciones históricas.\n   - En operaciones con liquidación en redes distribuidas (Categorías 3° y 4°), el campo `blockchain_tx_hash` (en `yohub_orders_book`) y `tx_hash` (en `yohub_ledger_entries`) almacena el identificador criptográfico de la transacción en la blockchain (`TXID` de 64 caracteres hexadecimales), protegido por el índice único `idx_unique_external_deposit_proof_agnostic` para impedir la doble acreditación de un mismo evento on-chain.\n\n### 2.4. Vinculación con el Legajo KYC/KYB del Cliente (Persona Humana y Persona Jurídica)\nNinguna orden puede existir de forma anónima ni disociada de su titular verificado:\n1. Toda fila en `public.yohub_orders_book` posee clave foránea obligatoria (`NOT NULL`) hacia `public.wallet_users(id)` y hacia la entidad PSAV `public.corporates(id)` (`corporate_id`).\n2. Al momento de la inserción, el trigger `fn_immutable_orders_book_art11()` consulta `public.wallet_users` y estampa de forma inmutable en la propia fila de la orden:\n   - `client_tax_id`: El número de **CUIT, CUIL o DNI** del cliente (`COALESCE(wu.cuit_cuil, wu.id_number)`).\n   - `client_person_type`: La clasificación jurídica del titular (`'HUMANA'` o `'JURIDICA'`) tomada de `wallet_users.person_type`.\n3. **Trazabilidad hacia el Legajo Documental Aislado por Sujeto Obligado**:\n   - **Personas Humanas (`client_person_type = 'HUMANA'`)**: El `user_id` enlaza con `public.global_identities`, cuyo atributo `compliance_data -> 'tenant_dossiers' -> [corporate_id]` conserva el legajo de Debida Diligencia del Cliente (biometría facial Didit v3 / Sumsub, prueba de vida, validación RENAPER, declaración jurada PEP, sujeto obligado UIF, residencia fiscal CRS/FATCA y resultado de cribado en listas RePET, ONU y OFAC).\n   - **Personas Jurídicas (`client_person_type = 'JURIDICA'`)**: El registro enlaza adicionalmente con `public.b2b_entities`, donde obran el estatuto social, acta de designación de autoridades, registro de Beneficiarios Finales (>= 10% de participación conforme Res. UIF N° 49/2024), inscripción AFIP/ARCA y poderes de los representantes legales autorizados a operar.\n\n### 2.5. Mecanismos de Inmutabilidad Criptográfica WORM y Conservación por 10 Años (Art. 38)\nPara garantizar que ninguna oferta ingresada ni operación registrada pueda ser alterada, sobrescrita o eliminada física o lógicamente durante el plazo legal mínimo de **DIEZ (10) años** (Art. 38 RG CNV N° 1058/25), la base de datos implementa tres anillos de defensa criptográfica a nivel de motor PostgreSQL:\n1. **Trigger WORM en el Libro de Órdenes (`trg_immutable_orders_book_art11`)**:\n   - Intercepta cualquier sentencia `DELETE` sobre `public.yohub_orders_book` y aborta la transacción arrojando la excepción `ART11_RG1058_DELETE_FORBIDDEN`.\n   - Intercepta cualquier sentencia `UPDATE` que intente modificar los atributos originales de la oferta (`order_id`, `corporate_id`, `user_id`, `order_type`, `psav_category`, `base_asset`, `quote_asset`, `offered_amount`, `order_ingested_at`, `client_tax_id`, `client_person_type`), abortando la transacción con `ART11_RG1058_IMMUTABILITY_VIOLATION`. Únicamente se permite la transición controlada de `status`, `executed_amount`, `registered_at`, `transaction_group_id` y `blockchain_tx_hash` cuando una orden en tránsito pasa a estado final liquidado.\n   - Calcula y sella en la columna `record_sha256` el digest criptográfico `SHA-256` (`extensions.digest(..., 'sha256')`) sobre la concatenación canónica de todos los atributos de la orden.\n2. **Trigger WORM y Cadena de Bloques Interna en el Libro Mayor (`trg_immutable_ledger_entries`)**:\n   - Prohíbe en forma absoluta cualquier `UPDATE` o `DELETE` sobre `public.yohub_ledger_entries`. Cualquier ajuste contable o reversa debe instrumentarse exclusivamente mediante un nuevo asiento compensatorio de partida doble (`CLEARING_ADJUSTMENT` o `REVERSAL`) vinculado al asiento original mediante `parent_entry_id` y `root_transaction_group_id`.\n   - Cada asiento incorpora en su cálculo de `current_hash` (`SHA-256`) el hash exacto del asiento inmediato anterior de la misma cuenta (`prev_hash`), formando una estructura encadenada donde la alteración de un solo bit histórico invalidaría toda la cadena subsiguiente.\n3. **Sellado Diario de Árbol de Merkle (`public.bcra_daily_ledger_seals`)**:\n   - Al cierre de cada jornada operativa, el motor consolida los hashes de todas las operaciones y saldos de Cuentas de Orden en una Raíz de Merkle (`merkle_root_hash` SHA-256), la cual queda asentada y disponible para verificación pública en `/api/cnv/proof-of-reserves` y `/cnv-transparencia`.\n\n---\n\n## 3. PROCEDIMIENTOS TÉCNICOS DE TRATAMIENTO DE ÓRDENES POR CATEGORÍA (ART. 11 PÁRRAFO 2° — CATEGORÍAS 1° A 5°)\n\nDe conformidad con el segundo párrafo del Artículo 11 de la RG CNV N° 1058/25 y el Artículo 4° bis de la Ley N° 25.246, se detallan a continuación los procedimientos técnicos de procesamiento para cada una de las cinco (5) categorías operativas:\n\n### 3.1. Categoría 1°: Intercambio entre Activos Virtuales y Monedas de Curso Legal (Monedas Fiduciarias ARS / USD)\nComprende las órdenes de compra (`order_type = 'BUY'`, `psav_category = 1`) y venta (`order_type = 'SELL'`, `psav_category = 1`) de Activos Virtuales contra Pesos Argentinos (`ARS`) o Dólares Estadounidenses (`USD`):\n1. **Ingreso y Conciliación de Fondos Fiduciarios (In-Ramp Bancario)**:\n   - El cliente transfiere fondos desde una cuenta bancaria o de pago de su propia titularidad hacia la cuenta recaudadora de **Cuentas de Orden** del PSAV abierta en la Entidad Financiera Patrocinadora (**Banco Coinag S.A. APIs v4.9 / Banco CMF / Red COELSA**), operando bajo el esquema de salto transaccional de **CVU Corta a CBU Larga Recaudadora** exenta del Impuesto sobre los Créditos y Débitos Bancarios conforme al **Decreto PEN N° 475/2026 y RG ARCA N° 5869/2026**.\n   - El webhook bancario autenticado (`/api/webhooks/sponsor-bank/transferencia`) verifica la regla de **Misma Titularidad (*Same-Name Rule* — BCRA Com. \"A\" 7340 y Art. 18 RG CNV 1058/25)** cotejando el CUIT/CUIL del originante informado por COELSA contra el `cuit_cuil` del legajo del usuario en `public.wallet_users`. Si los CUIT/CUIL no coinciden o provienen de terceros no autorizados, el depósito es rechazado o retenido preventivamente.\n   - El sistema almacena la evidencia forense del movimiento bancario (incluyendo la trama cruda de 180 caracteres en `public.bank_clearing_items.raw_line` durante la conciliación SFTP D-1 de lotes COELSA DEBIN Fase 4 v5.0 y Movimientos PSP 1.1) y acredita el saldo fiduciario en la cuenta `MEMORANDUM_CLIENT` del usuario.\n2. **Ingreso de la Oferta de Compra/Venta y Reserva de Saldo**:\n   - Cuando el cliente instruye la compra (`ARS -> USDT`) o venta (`USDT -> ARS`), el sistema registra la oferta en `public.yohub_orders_book` con `psav_category = 1` y `order_ingested_at = clock_timestamp()`.\n   - Se bloquea pesimistamente la cuenta de origen (`SELECT ... FOR UPDATE`) y se transfiere el monto ofertado de `current_balance` a `locked_balance`.\n3. **Calce contra Proveedor de Liquidez y Liquidación en Partida Doble**:\n   - La orden se ejecuta contra el libro interno o se rutea hacia el proveedor de liquidez institucional regulado (`Bit2Me` — convenio registrado bajo el Art. 35 RG CNV 1058/25 en `public.bcra_third_party_registry`) mediante el patrón *Transactional Outbox*.\n   - Confirmado el calce, dentro de una única transacción atómica PostgreSQL se consume el `locked_balance`, se asientan las partidas de débito y crédito en `public.yohub_ledger_entries` (verificando Suma Cero = 0 en el `transaction_group_id`), y se sella `registered_at = clock_timestamp()` y `record_sha256` en `public.yohub_orders_book`.\n4. **Egreso Fiduciario (Off-Ramp Bancario)**:\n   - En órdenes de venta con retiro fiduciario hacia CBU/CVU externo, el sistema valida previamente la titularidad de la cuenta destino en COELSA y liquida la transferencia inmediata registrando el identificador COELSA/OBID en el asiento contable.\n\n### 3.2. Categoría 2°: Intercambio entre Una o Más Formas de Activos Virtuales (Swap Cripto-a-Cripto)\nComprende las órdenes de conversión directa entre distintos Activos Virtuales (`order_type = 'SWAP'`, `psav_category = 2`, ej. `BTC <-> USDT`, `ETH <-> USDC`):\n1. **Fijación de Cotización Firme y *Quote Locking* Criptográfico (Art. 31)**:\n   - Previo a la confirmación del cliente, el motor de cotizaciones (`/api/wallet/transfer/quote` y `/api/wallet/swap-internal`) consulta el precio en tiempo real del Oráculo institucional y aplica de forma transparente el diferencial (*spread*) máximo parametrizado para el Tenant en `public.corporate_cnv_psav_configs.fee_crypto_swap_max_spread_bps` (Art. 31 RG CNV 1058/25).\n   - El servidor emite un token de cotización firmado con **HMAC-SHA256** que incluye el par (`base_asset`, `quote_asset`), la tasa exacta (`execution_price`), la comisión desglosada (`fee_amount`) y un tiempo de expiración determinista (TTL).\n2. **Prioridad Temporal Estricta FIFO (*First-In, First-Out*) Anti-Front-Running (Arts. 24 inc. e y 26)**:\n   - Las órdenes ingresadas se procesan en estricto orden cronológico de recepción según su marca temporal `order_ingested_at` y su secuencia monótona.\n   - La plataforma no realiza operaciones de *proprietary trading* con ventaja informativa ni reordena colas de ejecución, garantizando neutralidad absoluta y ausencia de *front-running*.\n3. **Asiento Contable Atómico Multi-Pata**:\n   - La función transaccional ejecuta en una sola unidad de trabajo (`BEGIN ... COMMIT`):\n     - Débito del activo entregado (`SWAP_DEBIT`) en la cuenta `MEMORANDUM_CLIENT` del usuario;\n     - Crédito del activo recibido (`SWAP_CREDIT`) en la cuenta `MEMORANDUM_CLIENT` del usuario;\n     - Contrapartida simétrica en las cuentas ómnibus segregadas (`OMNIBUS_MASTER`) de ambos activos;\n     - Imputación de la comisión devengada en la cuenta de resultados del PSAV (`REVENUE_FEE` en el plano `PATRIMONIAL_OWN`).\n   - Se registra la orden en `public.yohub_orders_book` con `psav_category = 2`, `status = 'EXECUTED'` y sello `record_sha256`.\n\n### 3.3. Categoría 3°: Transferencia de Activos Virtuales\nComprende toda instrucción de envío o recepción de Activos Virtuales (`order_type = 'TRANSFER'`, `psav_category = 3`), distinguiendo técnicamente dos modalidades:\n1. **Transferencias Internas entre Clientes en el Libro Mayor (*Off-Chain Book-Entry*)**:\n   - Cuando el destinatario es otro usuario registrado en la infraestructura (`INTERNAL_TRANSFER` o `CROSS_TENANT_TRANSFER`), la liquidación se realiza íntegramente dentro de PostgreSQL mediante la función `rpc_execute_federated_transfer`.\n   - No se incurre en costo de gas de red blockchain (comisión `0.00%` bonificada según Cuadro Tarifario Art. 31), la acreditación es instantánea (sub-segundo) y el movimiento queda asentado simultáneamente en `public.yohub_orders_book` (`psav_category = 3`) y en `public.yohub_ledger_entries`.\n2. **Transferencias Externas hacia o desde Direcciones en la Blockchain (*On-Chain Transfers*)**:\n   - **Cumplimiento Automatizado de la Regla de Viaje (*Travel Rule* — Art. 26 Res. UIF N° 49/2024)**: En toda transferencia cuyo importe en dólares estadounidenses iguale o supere el equivalente a **TRES (3) Salarios Mínimos, Vitales y Móviles (`3 * SMVM`)** —o el umbral paramétrico inferior configurado en `public.yohub_regulatory_parameters`—, el motor exige y persiste en `public.travel_rule_records` los datos completos del originante (`originator_name`, `originator_id_number`), del beneficiario (`beneficiary_name`, `beneficiary_type`), el PSAV/VASP de destino (`beneficiary_vasp_name`), la dirección de billetera (`destination_wallet_address`) y la declaración jurada de titularidad en caso de billeteras auto-custodiadas (*unhosted wallets*, `unhosted_ownership_declared`).\n   - **Compuerta de Lista Blanca Obligatoria con Enfriamiento de 24 Horas (Art. 17 inc. d RG CNV 1058/25)**: Ningún retiro on-chain puede ejecutarse hacia una dirección externa que no se encuentre previamente registrada y verificada en `public.yohub_whitelisted_addresses` para ese `user_id` y `corporate_id`, habiendo transcurrido el período de enfriamiento (*cooldown*) mínimo de **VEINTICUATRO (24) horas** parametrizado en `corporate_cnv_psav_configs.whitelist_cooldown_hours`.\n   - **Paridad Custodial vs. Non-Custodial (Smart Accounts ERC-4337)**: En billeteras de abstracción de cuenta (ERC-4337), el sistema verifica criptográficamente el recibo de ejecución y el `tx_hash` real en el nodo RPC antes de impactar el espejo contable.\n\n### 3.4. Categoría 4°: Custodia y/o Administración de Activos Virtuales\nComprende el resguardo técnico, administración de claves criptográficas, detección de depósitos on-chain (`order_type = 'CUSTODY_DEPOSIT'`, `psav_category = 4`), procesamiento de retiros (`order_type = 'CUSTODY_WITHDRAWAL'`, `psav_category = 4`) y conciliación de reservas:\n1. **Procedimiento Técnico de Detección y Acreditación de Depósitos On-Chain**:\n   - Los servicios de indexación y webhooks autenticados (`/api/webhooks/gateway/[provider]` con validación de firma criptográfica HMAC-SHA512 y control de repetición *anti-replay*) monitorean las direcciones de depósito asignadas.\n   - Para prevenir ataques de reorganización de cadena (*chain reorgs*) o doble gasto, el sistema exige alcanzar el número mínimo de confirmaciones definitivas antes de cambiar el estado a acreditado:\n     - **Red Polygon PoS**: mínimo **64 bloques** confirmados;\n     - **Red Bitcoin Mainnet**: mínimo **3 bloques** minados;\n     - **Red Ethereum Mainnet**: estado de finalidad PoS (**Finalized Checkpoint** >= 2 épocas / 64 slots);\n     - **Red TRON Mainnet (TRC-20)**: mínimo **19 bloques Solidified** confirmados por Super Representantes;\n     - **Redes Ethereum L2 (Arbitrum / Optimism / Base)**: confirmación de lote publicado en L1 (*L1 Batch Finality*).\n   - **Blindaje Anti-Emisión Ficticia (*Agnostic Proof of Deposit Invariant*)**: El trigger de base de datos valida que todo asiento `EXTERNAL_DEPOSIT` posea su prueba criptográfica de depósito verificada (`tx_hash` on-chain o referencia de cámara COELSA); cualquier intento de inyectar saldo sin respaldo arroja la excepción `UNBACKED_DEPOSIT_REJECTED`. Asimismo, el índice único `idx_unique_external_deposit_proof_agnostic` garantiza idempotencia absoluta.\n2. **Política de Custodia Térmica y Segregación en Cuentas de Orden (Arts. 14, 15, 16 y 17)**:\n   - Todos los activos de clientes se contabilizan en el plano `MEMORANDUM_CLIENT`, separados del plano `PATRIMONIAL_OWN`.\n   - La distribución física de los activos en custodia respeta la relación paramétrica auditada en `public.corporate_cnv_psav_configs`:\n     - **Bóveda Fría (*Cold Vault* — HSM / Air-Gapped / MPC)**: mínimo **70%** (`cold_vault_min_pct >= 70`);\n     - **Billetera Tibia (*Warm Wallet*)**: máximo **20%** (`warm_wallet_max_pct <= 20`);\n     - **Billetera Caliente (*Hot Wallet* transaccional)**: máximo **10%** (`hot_wallet_max_pct <= 10`);\n     - Con validación estricta Hot + Warm + Cold = 100%.\n3. **Gobernanza Multifirma por Umbral (Art. 17 inc. c) y Emisión de Retiros vía HSM/MPC**:\n   - Todo retiro o movimiento de tesorería desde custodia cuyo valor equivalente iguale o supere el umbral de seguridad parametrizado (**USD 10.000,00** en `multisig_cold_threshold_usd`) requiere obligatoriamente esquema de firma mancomunada **2-de-3 (`2_OF_3`)** registrado en `public.yohub_multisig_approvals`, con intervención de al menos dos oficiales autorizados bajo Principio de Control Dual (4 Ojos) y autenticación biométrica FIDO2/WebAuthn Level 3 antes de que el módulo HSM/MPC transmita la transacción a la red.\n\n### 3.5. Categoría 5°: Servicios Financieros Relacionados con la Oferta de un Emisor y/o Venta de un Activo Virtual (Colocación Primaria)\nComprende la participación y prestación de servicios financieros vinculados a la emisión o colocación primaria de un Activo Virtual (`order_type = 'PRIMARY_ISSUANCE'`, `psav_category = 5`):\n1. **Debida Diligencia Reforzada del Emisor y Segregación por Emisión**:\n   - Previo a habilitar cualquier proyecto en Categoría 5°, el Comité de Cumplimiento ejecuta la debida diligencia reforzada (KYB, Beneficiarios Finales, auditoría técnica del contrato inteligente y dictamen legal sobre la naturaleza jurídica del token) y requiere aprobación expresa por Acta de Directorio conforme a `category_5_primary_issuance_policy`.\n2. **Validación Previa Obligatoria del Whitepaper Oficial (Art. 37 RG CNV 1058/25)**:\n   - El activo debe encontrarse dado de alta en `public.yohub_products` cumpliendo los once (11) recaudos informativos del Artículo 37: identificación del emisor (`issuer_info`), resumen de riesgos técnicos y económicos (`art37_risk_summary`), fecha de lanzamiento (`launch_date`), enlace público permanente al documento técnico fundacional (`whitepaper_url`) y sello criptográfico de integridad de 64 caracteres hexadecimales (`whitepaper_sha256`).\n   - Cuando la antigüedad del Activo Virtual desde su `launch_date` sea inferior a **NOVENTA (90) días corridos** (`is_under_90_days = true`), la plataforma lo exhibe en una sección segregada con advertencia de riesgo reforzada conforme al último párrafo del Artículo 36.\n   - El trigger `trg_enforce_cat5_security_gate` en `public.yohub_products` y el trigger `trg_immutable_orders_book_art11` en `public.yohub_orders_book` rechazan con la excepción `CAT5_WHITEPAPER_REQUIRED_ART37` cualquier intento de activar un activo o cursar una orden `PRIMARY_ISSUANCE` si `whitepaper_url` o `whitepaper_sha256` (64 chars hex) se encuentran vacíos o incompletos.\n3. **Bloqueo Técnico Determinista de Valores Negociables sin Oferta Pública CNV (Ley N° 26.831 Art. 2)**:\n   - El catálogo de productos incluye el atributo booleano `is_negotiable_security`, el indicador `cnv_public_offering_authorized` y el campo `cnv_offering_resolution`.\n   - Si un activo representa un derecho de crédito, participación societaria, instrumento de deuda soberana/corporativa o contrato de inversión alcanzado por el **Artículo 2° de la Ley N° 26.831** (por ejemplo, el activo `TBILL_RWA` — *Tokenized US T-Bill RWA*, marcado con `is_negotiable_security = true`), **queda bloqueado determinísticamente a nivel de motor de base de datos PostgreSQL** (`is_active = false`, `cat5_primary_issuance_enabled = false`).\n   - El trigger `trg_enforce_cat5_security_gate` impide activar (`is_active = true`) o habilitar la colocación primaria (`cat5_primary_issuance_enabled = true`), y el trigger `trg_immutable_orders_book_art11` impide insertar órdenes sobre dicho activo mientras `cnv_public_offering_authorized` sea `false` o carezca de número de Resolución de Oferta Pública de la CNV (`cnv_offering_resolution`), arrojando de forma inmediata el error `SECURITY_TOKEN_REQUIRES_CNV_PUBLIC_OFFERING_AUTH`.\n\n---\n\n## 4. VALIDACIONES PRE-TRANSACCIONALES Y CONTROL DE CONCURRENCIA\n\n### 4.1. Las Seis (6) Validaciones Automáticas Pre-Transaccionales Síncronas\nNinguna oferta ingresada al sistema puede pasar a ejecución sin superar de manera síncrona y satisfactoria las siguientes seis (6) compuertas automáticas:\n1. **Compuerta 1 — Estado del Legajo KYC/KYB y Listas Restrictivas PLA/FT**: Verificación en `public.wallet_users` y `global_identities.compliance_data.tenant_dossiers[corporate_id]` de que el cliente posee estado `APPROVED` / `VERIFIED_ALL`, sin bloqueos preventivos ni alertas críticas abiertas en `public.compliance_alerts` (RePET, ONU, OFAC, GAFI).\n2. **Compuerta 2 — Aceptación Expresa de la DDJJ de Riesgos (Art. 36) y Términos de Cuentas de Orden (Art. 16)**: Verificación en `public.corporate_legal_acceptances` de que el usuario ha firmado digitalmente la versión vigente de `DDJJ_RIESGOS_ART36` (incisos `a` a `l`) y `TNC_CUENTAS_DE_ORDEN_ART16_18_19`.\n3. **Compuerta 3 — Evaluación del Perfil Transaccional Dinámico Indexado en SMVM (Res. UIF N° 49/2024)**: Invocación a la función PL/pgSQL `public.rpc_evaluate_transactional_profile`, que calcula el monto de la orden en USD y valida que no exceda:\n   - El tope máximo por transacción (`max_per_tx_usd`);\n   - El acumulado móvil de las últimas **24 horas** (`max_daily_usd`);\n   - El acumulado móvil de los últimos **30 días** (`max_monthly_usd` / multiplicador SMVM mensual);\n   - El acumulado móvil de los últimos **365 días** (`max_annual_usd` / multiplicador SMVM anual).\n4. **Compuerta 4 — Disponibilidad de Saldo Libre de Bloqueos e Invariante de Saldo No Negativo (BCRA PSPCP 4.1.2)**: Verificación matemática en precisión `NUMERIC(36, 18)` de que la cuenta de origen posee saldo disponible suficiente (`current_balance - locked_balance >= offered_amount + fee_amount`). El motor tiene prohibido otorgar descubiertos o permitir saldos negativos (`CHECK (current_balance >= 0 AND locked_balance >= 0)`).\n5. **Compuerta 5 — Reglas de Producto, Red, Travel Rule y Whitelist 24h**: Verificación de que el activo permite la dirección del flujo (`default_allow_inbound` / `default_allow_outbound`), que en retiros on-chain la dirección destino cumple las 24 horas de enfriamiento en `yohub_whitelisted_addresses` (Art. 17 inc. d) y que se ha integrado el registro de `travel_rule_records` si el monto es >= 3 SMVM.\n6. **Compuerta 6 — Compuerta de Categoría 5°, Whitepaper Art. 37 e Incompatibilidad Ley 26.831**: Verificación por los triggers `trg_enforce_cat5_security_gate` y `trg_immutable_orders_book_art11` de que el activo posee `whitepaper_sha256` válido y no constituye un Valor Negociable sin autorización de oferta pública de la CNV.\n\n### 4.2. Mecanismo de Bloqueo Transaccional Pesimista y Control de Concurrencia\nPara garantizar atomicidad (`ACID`), aislamiento serializable efectivo sobre saldos y ausencia total de condiciones de carrera (*race conditions*) o interbloqueos (*deadlocks*) bajo alta concurrencia:\n1. **Bloqueo Pesimista con Ordenamiento Lexicográfico Determinista Anti-Deadlock**:\n   - Cuando una operación involucra dos o más cuentas contables (ej. cuenta origen del cliente, cuenta destino, cuenta ómnibus y cuenta de comisiones), el procedimiento almacenado adquiere el bloqueo exclusivo de fila ejecutando:\n     ```sql\n     SELECT id, current_balance, locked_balance\n     FROM public.yohub_accounts\n     WHERE id = ANY(v_account_ids)\n     ORDER BY id ASC\n     FOR UPDATE;\n     ```\n   - Al ordenar los identificadores `UUID` en forma ascendente (`ORDER BY id ASC`) antes de adquirir los cerrojos `FOR UPDATE`, dos transacciones concurrentes cruzadas (ej. Usuario A transfiere a Usuario B al mismo milisegundo en que Usuario B transfiere a Usuario A) solicitan los bloqueos exactamente en el mismo orden canónico, **eliminando matemáticamente la posibilidad de un ciclo de espera (*deadlock*)**.\n2. **Reserva Atómica de Saldo en Tránsito (`locked_balance` — Saga Fase 1)**:\n   - En operaciones asíncronas que dependen de confirmación externa (liquidación en blockchain o cámara compensadora bancaria), la Fase 1 deduce el importe de `current_balance` o lo compromete en `locked_balance` dentro de la misma transacción en que la orden ingresa a `yohub_orders_book` (`status = 'PENDING_SETTLEMENT'`). Si el cliente envía múltiples peticiones simultáneas (*double-click* o ataque de concurrencia), la segunda petición encuentra el cerrojo `FOR UPDATE` y, al liberarse, verifica el saldo ya disminuido, siendo rechazada de inmediato por saldo insuficiente.\n3. **Secuencia Monótona por Cuenta (`account_seq`) e Invariante Diferida de Suma Cero**:\n   - Cada inserción en `public.yohub_ledger_entries` asigna `account_seq = COALESCE(MAX(account_seq), 0) + 1` bajo el cerrojo de la cuenta.\n   - Al finalizar la transacción (`DEFERRABLE INITIALLY DEFERRED`), el constraint trigger `fn_enforce_zero_sum_transaction_group` comprueba que la suma algebraica de todos los movimientos del `transaction_group_id` por moneda sea exactamente igual a cero (`SUM(amount) = 0.000000000000000000`). En caso de discrepancia de siquiera 1e-18 unidades, la transacción completa hace `ROLLBACK` automático.\n","sha256_hash":"SHA256:EFD8E0669F18A1339E6EBAF6EBE603C62F0B420A9E39687160DEA17876C0788C","board_approval_act":"Acta de Directorio PSAV 2026 — Aprobación Manual Técnico M01 (Art. 11 RG CNV N° 1058/25)","effective_from":"2026-10-16T21:40:40.212062+00:00","is_active":true},{"id":"0a109a28-78d1-46ab-8a2e-92070817250e","corporate_id":"711555e3-6c42-41f7-ae2d-fb4eb1a3e526","doc_type":"M01_MANUAL_SISTEMAS_ORDENES_ART11","version_tag":"v2.0-CNV1058-M01","title":"Manual de Procedimientos de Sistemas Informáticos, Tratamiento de Órdenes y Registro Cronológico al Segundo (Art. 11 RG CNV N° 1058/25)","normative_reference":"RG CNV N° 1058/25","summary_markdown":"# MANUAL DE PROCEDIMIENTOS DE SISTEMAS INFORMÁTICOS, TRATAMIENTO DE ÓRDENES Y REGISTRO CRONOLÓGICO AL SEGUNDO (M01)\n## RESOLUCIÓN GENERAL CNV N° 1058/2025 — ARTÍCULO 11 | LEY N° 27.739 | RESOLUCIÓN UIF N° 49/2024\n\n- **Código de Documento**: `M01_MANUAL_SISTEMAS_ORDENES_ART11`\n- **Versión Vigente**: `v2.0-CNV1058-M01` (Producción — Homologación Técnica Área de Sistemas CNV)\n- **Entidad Sujeto Obligado / PSAV**: Configurada por Tenant en `public.corporate_cnv_psav_configs` (incluyendo **DAV NEXT S.A.** — CUIT `30-71960008-1`)\n- **Órgano de Aprobación**: Directorio de la Sociedad — Acta de Directorio Fundacional PSAV 2026\n- **Responsables de Emisión y Control**: Responsable de Cumplimiento Regulatorio y Control Interno (Art. 21 RG CNV N° 1058/25), Oficial de Cumplimiento PLA/FT (Res. UIF N° 49/2024) y Dirección de Tecnología (CTO / Idóneo Informático Art. 20)\n\n---\n\n## 1. ENCUADRE NORMATIVO Y ALCANCE INSTITUCIONAL\n\nEl presente Manual de Procedimientos de Sistemas Informáticos, Tratamiento de Órdenes y Registro Cronológico al Segundo (en adelante, el **\"Manual M01\"**) establece la arquitectura técnica, las estructuras de datos inmutables, los algoritmos de sincronización horaria, los flujos transaccionales para las **Categorías 1° a 5° de Proveedores de Servicios de Activos Virtuales (PSAV)** y los mecanismos de control de concurrencia implementados en producción en el motor transaccional (**Ledger SSOT V5**).\n\nEl diseño e implementación técnica dan cumplimiento estricto y verificable al siguiente plexo normativo de la República Argentina:\n1. **Resolución General CNV N° 1058/2025 (Título XIV, Capítulo III de las Normas de la Comisión Nacional de Valores — T.O. 2013 y mod.)**:\n   - **Artículo 4° y Artículo 4° bis de la Ley N° 25.246 (mod. por Ley N° 27.739)**: Definición y alcance de las Cinco (5) Categorías de servicios sobre Activos Virtuales.\n   - **Artículo 11 (Sistemas Informáticos y Registro Cronológico al Segundo)**: Obligación de contar con sistemas informáticos que permitan registrar en forma cronológica, al segundo y con carácter inalterable, cada oferta ingresada y cada operación registrada con sus seis (6) atributos mínimos obligatorios, así como los procedimientos técnicos aplicables a cada categoría operativa.\n   - **Artículos 14, 15, 16, 17, 18 y 19 (Segregación Patrimonial en Cuentas de Orden, Prueba de Reservas y Custodia)**: Aislamiento matemático entre el patrimonio propio del PSAV (`PATRIMONIAL_OWN`) y los fondos/activos de terceros (`MEMORANDUM_CLIENT`), conciliación 1:1, custodia multifirma y prohibición de disposición de activos de clientes sin consentimiento expreso.\n   - **Artículo 20 (Auditoría Anual de Sistemas Informáticos)**: Trazabilidad criptográfica SHA-256 auditable por profesional independiente con competencia técnica.\n   - **Artículos 24 inc. e), 26 y 31 (Prioridad Temporal FIFO, Prevención de Front-Running y Transparencia Tarifaria)**: Ejecución estricta por orden de prelación temporal y divulgación previa de comisiones y spreads.\n   - **Artículos 36 y 37 (Divulgación de Riesgos al Consumidor y Régimen de Whitepapers)**: Exigencia de aceptación previa de los 12 riesgos regulatorios (incisos `a` a `l`), publicación de fichas técnicas oficiales (*Whitepapers*) con once (11) requisitos mínimos y advertencia destacada para Activos Virtuales con antigüedad inferior a NOVENTA (90) días corridos.\n   - **Artículo 38 (Conservación de la Documentación e Inmutabilidad por 10 Años)**: Preservación íntegra bajo modalidad *Write-Once-Read-Many* (WORM) durante un plazo mínimo de DIEZ (10) años.\n2. **Ley N° 26.831 de Mercado de Capitales (Artículo 2°)**: Delimitación e incompatibilidad técnica automática respecto de Activos Virtuales que constituyan **Valores Negociables** o contratos de inversión, los cuales se encuentran bloqueados a nivel motor de base de datos salvo autorización expresa de Oferta Pública otorgada por la CNV.\n3. **Resolución UIF N° 49/2024**: Régimen de Prevención de Lavado de Activos y Financiación del Terrorismo (PLA/FT/FPADM) para PSAV, incluyendo Perfil Transaccional Dinámico indexado en Salarios Mínimos, Vitales y Móviles (SMVM), monitoreo automatizado y cumplimiento de la Regla de Viaje (*Travel Rule* >= 3 SMVM).\n4. **Comunicaciones Técnicas del BCRA (Marco 2026 para Rieles Fiduciarios y PSPCP)**: Comunicaciones \"A\" 8406 (CIMPRA), \"A\" 8411 (Balance Cero diario con sellado Merkle), \"A\" 8469 (Cuentas Puente de Recaudación Suma Cero), \"A\" 8473 (Gobernanza Anti-Fraude e Interoperabilidad) y Punto 4.1.2 del T.O. de PSPCP (Invariante de Saldo No Negativo).\n\n---\n\n## 2. ESTRUCTURA DEL REGISTRO Y PRESERVACIÓN DE DATOS (ART. 11 PÁRRAFO 1°)\n\n### 2.1. Esquema Relacional del Libro de Órdenes (`public.yohub_orders_book`) y Libro Mayor (`public.yohub_ledger_entries`)\nEl sistema preserva de manera permanente e inalterable la totalidad de las ofertas ingresadas por los clientes y las operaciones liquidadas en dos estructuras relacionales vinculadas atómicamente en PostgreSQL:\n- **`public.yohub_orders_book` (Libro Electrónico de Ofertas y Órdenes — Art. 11)**: Registra el ciclo de vida completo de cada instrucción desde el microsegundo exacto de su recepción (`order_ingested_at`) hasta su ejecución y liquidación (`registered_at`).\n- **`public.yohub_ledger_entries` (Libro Mayor de Partida Doble — Arts. 15, 16 y 20)**: Registra los asientos contables atómicos en planos segregados asociados mediante `transaction_group_id`.\n\nA continuación se detalla el mapeo campo por campo de los **SEIS (6) datos mínimos obligatorios exigidos por el Artículo 11 párrafo 1° de la RG CNV N° 1058/25**:\n\n| N° | Requisito Normativo (Art. 11 párr. 1° RG 1058/25) | Columna en `public.yohub_orders_book` | Columna en `public.yohub_ledger_entries` | Tipo de Dato y Restricción en Motor PostgreSQL |\n| :--- | :--- | :--- | :--- | :--- |\n| **1** | **Fecha, hora, minutos y segundos en que ingresaron como ofertas al sistema** | `order_ingested_at` | `order_ingested_at` | `TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp()` — Capturado en el instante de ingreso de la oferta a la API BFF. |\n| **2** | **Fecha, hora, minutos y segundos en que fueron registradas en el sistema** | `registered_at` | `settled_at` / `created_at` | `TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp()` — Invariante controlada por trigger: `registered_at >= order_ingested_at`. |\n| **3** | **Cantidad ofertada (para compra y/o venta, conversión, transferencia o custodia)** | `offered_amount`, `executed_amount`, `execution_price`, `fee_amount`, `order_type`, `psav_category` | `amount`, `amount_usd`, `fx_rate_usd`, `entry_type` | `NUMERIC(36, 18) NOT NULL` — Cero punto flotante. Categoría PSAV `SMALLINT CHECK (psav_category BETWEEN 1 AND 5)`. |\n| **4** | **Tipo de Activo Virtual (AV)** | `base_asset`, `quote_asset` | `currency` | `VARCHAR NOT NULL` — Validado contra catálogo maestro `public.yohub_products.symbol` (ej. `BTC`, `ETH`, `USDT`, `USDC`, `DAI`, `TRX`, `ARS`, `USD`). |\n| **5** | **Identificador interno o código HASH en caso de haber sido registrada en blockchain** | `order_id` (PK), `transaction_group_id`, `blockchain_tx_hash`, `record_sha256` | `entry_id` (PK), `transaction_group_id`, `account_seq`, `tx_hash`, `prev_hash`, `current_hash` | `UUID v4` para identificadores internos, `BIGINT` monótono para `account_seq`, `TEXT` para `TXID` on-chain y `VARCHAR(64)` para sello SHA-256. |\n| **6** | **Identificación del cliente (Persona Humana o Persona Jurídica)** | `user_id`, `client_tax_id`, `client_person_type` | `account_id -> yohub_accounts.user_id` | `UUID v4 NOT NULL` FK a `public.wallet_users(id)`, `client_tax_id VARCHAR(32)` (CUIT/CUIL/DNI) y `client_person_type VARCHAR(20)` (`'HUMANA'` / `'JURIDICA'`). |\n\n### 2.2. Sincronización Horaria Atómica (Protocolo NTP Estrato 1 y Estándar ISO 8601 UTC-3)\n1. **Fuente de Tiempo Oficial (`ntp_sync_source`)**: Todos los nodos de aplicación y el clúster de base de datos sincronizan su reloj del sistema mediante el protocolo **NTP (Network Time Protocol) Estrato 1** provisto por **AWS Time Sync Service (`169.254.169.123`)**, conectado a una flota de relojes atómicos de Cesio y receptores satelitales GPS redundantes, con desviación máxima controlada inferior a 1 milisegundo (< 1 ms).\n2. **Estampado al Microsegundo en Motor Transaccional**: A diferencia de la función `now()` (que congela el tiempo al inicio del bloque transaccional), los procedimientos almacenados y triggers del Libro de Órdenes y del Libro Mayor invocan **`clock_timestamp()`**, capturando el tiempo real de reloj de pared con resolución de microsegundos.\n3. **Representación y Huso Horario Oficial Argentino**: Los registros se almacenan en tipo `TIMESTAMPTZ` (UTC absoluto con desplazamiento horario) y se exponen en todas las APIs regulatorias, reportes TAD y consolas de auditoría en formato estándar **ISO 8601 (`YYYY-MM-DDTHH:mm:ss.sss-03:00`)** bajo el huso horario oficial de la República Argentina (**`America/Argentina/Buenos_Aires` — UTC-3**).\n4. **Invariante de Prelación Cronológica**: El trigger `trg_immutable_orders_book_art11` verifica en cada inserción o actualización de estado que `NEW.registered_at >= NEW.order_ingested_at`. Cualquier intento de registrar una ejecución con marca temporal anterior al ingreso de la oferta es abortado inmediatamente con la excepción `CHRONOLOGICAL_ORDER_VIOLATION_ART11`.\n\n### 2.3. Precisión Decimal Exacta y Trazabilidad de Identificadores\n1. **Prohibición Absoluta de Punto Flootante**: Queda estrictamente prohibido en toda la arquitectura el uso de tipos `FLOAT`, `REAL`, `DOUBLE PRECISION` en SQL o `parseFloat()` / `Number()` en TypeScript para cálculos monetarios.\n   - **Base de Datos (PostgreSQL)**: Todos los importes (`offered_amount`, `executed_amount`, `execution_price`, `fee_amount`, `amount`, `current_balance`, `locked_balance`) utilizan `NUMERIC(36, 18)`.\n   - **Capa BFF / Servicios (Node.js / TypeScript)**: Toda la aritmética financiera y de conversión se procesa con la librería **`Decimal.js`** configurada con `precision: 36` y redondeo determinista `Decimal.ROUND_DOWN` bajo el contrato de precisión `v2_strict_decimal`.\n   - **Capa Cliente**: Los importes se serializan como cadenas de texto (`string`) o enteros de precisión arbitraria (`BigInt`) expresados en unidades atómicas (*wei*, *satoshis*, centavos).\n2. **Asociación Unívoca con Identificadores Internos y Hashes de Blockchain**:\n   - Cada oferta recibe al ingresar un `order_id` (`UUID v4`) único.\n   - Al ejecutarse contablemente, se vincula de forma inmutable con un `transaction_group_id` (`UUID v4`) que agrupa todas las patas de partida doble en `public.yohub_ledger_entries`.\n   - Cada cuenta afectada incrementa su número de secuencia estrictamente monótono (`account_seq BIGINT`), impidiendo intercalar o reordenar operaciones históricas.\n   - En operaciones con liquidación en redes distribuidas (Categorías 3° y 4°), el campo `blockchain_tx_hash` (en `yohub_orders_book`) y `tx_hash` (en `yohub_ledger_entries`) almacena el identificador criptográfico de la transacción en la blockchain (`TXID` de 64 caracteres hexadecimales), protegido por el índice único `idx_unique_external_deposit_proof_agnostic` para impedir la doble acreditación de un mismo evento on-chain.\n\n### 2.4. Vinculación con el Legajo KYC/KYB del Cliente (Persona Humana y Persona Jurídica)\nNinguna orden puede existir de forma anónima ni disociada de su titular verificado:\n1. Toda fila en `public.yohub_orders_book` posee clave foránea obligatoria (`NOT NULL`) hacia `public.wallet_users(id)` y hacia la entidad PSAV `public.corporates(id)` (`corporate_id`).\n2. Al momento de la inserción, el trigger `fn_immutable_orders_book_art11()` consulta `public.wallet_users` y estampa de forma inmutable en la propia fila de la orden:\n   - `client_tax_id`: El número de **CUIT, CUIL o DNI** del cliente (`COALESCE(wu.cuit_cuil, wu.id_number)`).\n   - `client_person_type`: La clasificación jurídica del titular (`'HUMANA'` o `'JURIDICA'`) tomada de `wallet_users.person_type`.\n3. **Trazabilidad hacia el Legajo Documental Aislado por Sujeto Obligado**:\n   - **Personas Humanas (`client_person_type = 'HUMANA'`)**: El `user_id` enlaza con `public.global_identities`, cuyo atributo `compliance_data -> 'tenant_dossiers' -> [corporate_id]` conserva el legajo de Debida Diligencia del Cliente (biometría facial Didit v3 / Sumsub, prueba de vida, validación RENAPER, declaración jurada PEP, sujeto obligado UIF, residencia fiscal CRS/FATCA y resultado de cribado en listas RePET, ONU y OFAC).\n   - **Personas Jurídicas (`client_person_type = 'JURIDICA'`)**: El registro enlaza adicionalmente con `public.b2b_entities`, donde obran el estatuto social, acta de designación de autoridades, registro de Beneficiarios Finales (>= 10% de participación conforme Res. UIF N° 49/2024), inscripción AFIP/ARCA y poderes de los representantes legales autorizados a operar.\n\n### 2.5. Mecanismos de Inmutabilidad Criptográfica WORM y Conservación por 10 Años (Art. 38)\nPara garantizar que ninguna oferta ingresada ni operación registrada pueda ser alterada, sobrescrita o eliminada física o lógicamente durante el plazo legal mínimo de **DIEZ (10) años** (Art. 38 RG CNV N° 1058/25), la base de datos implementa tres anillos de defensa criptográfica a nivel de motor PostgreSQL:\n1. **Trigger WORM en el Libro de Órdenes (`trg_immutable_orders_book_art11`)**:\n   - Intercepta cualquier sentencia `DELETE` sobre `public.yohub_orders_book` y aborta la transacción arrojando la excepción `ART11_RG1058_DELETE_FORBIDDEN`.\n   - Intercepta cualquier sentencia `UPDATE` que intente modificar los atributos originales de la oferta (`order_id`, `corporate_id`, `user_id`, `order_type`, `psav_category`, `base_asset`, `quote_asset`, `offered_amount`, `order_ingested_at`, `client_tax_id`, `client_person_type`), abortando la transacción con `ART11_RG1058_IMMUTABILITY_VIOLATION`. Únicamente se permite la transición controlada de `status`, `executed_amount`, `registered_at`, `transaction_group_id` y `blockchain_tx_hash` cuando una orden en tránsito pasa a estado final liquidado.\n   - Calcula y sella en la columna `record_sha256` el digest criptográfico `SHA-256` (`extensions.digest(..., 'sha256')`) sobre la concatenación canónica de todos los atributos de la orden.\n2. **Trigger WORM y Cadena de Bloques Interna en el Libro Mayor (`trg_immutable_ledger_entries`)**:\n   - Prohíbe en forma absoluta cualquier `UPDATE` o `DELETE` sobre `public.yohub_ledger_entries`. Cualquier ajuste contable o reversa debe instrumentarse exclusivamente mediante un nuevo asiento compensatorio de partida doble (`CLEARING_ADJUSTMENT` o `REVERSAL`) vinculado al asiento original mediante `parent_entry_id` y `root_transaction_group_id`.\n   - Cada asiento incorpora en su cálculo de `current_hash` (`SHA-256`) el hash exacto del asiento inmediato anterior de la misma cuenta (`prev_hash`), formando una estructura encadenada donde la alteración de un solo bit histórico invalidaría toda la cadena subsiguiente.\n3. **Sellado Diario de Árbol de Merkle (`public.bcra_daily_ledger_seals`)**:\n   - Al cierre de cada jornada operativa, el motor consolida los hashes de todas las operaciones y saldos de Cuentas de Orden en una Raíz de Merkle (`merkle_root_hash` SHA-256), la cual queda asentada y disponible para verificación pública en `/api/cnv/proof-of-reserves` y `/cnv-transparencia`.\n\n---\n\n## 3. PROCEDIMIENTOS TÉCNICOS DE TRATAMIENTO DE ÓRDENES POR CATEGORÍA (ART. 11 PÁRRAFO 2° — CATEGORÍAS 1° A 5°)\n\nDe conformidad con el segundo párrafo del Artículo 11 de la RG CNV N° 1058/25 y el Artículo 4° bis de la Ley N° 25.246, se detallan a continuación los procedimientos técnicos de procesamiento para cada una de las cinco (5) categorías operativas:\n\n### 3.1. Categoría 1°: Intercambio entre Activos Virtuales y Monedas de Curso Legal (Monedas Fiduciarias ARS / USD)\nComprende las órdenes de compra (`order_type = 'BUY'`, `psav_category = 1`) y venta (`order_type = 'SELL'`, `psav_category = 1`) de Activos Virtuales contra Pesos Argentinos (`ARS`) o Dólares Estadounidenses (`USD`):\n1. **Ingreso y Conciliación de Fondos Fiduciarios (In-Ramp Bancario)**:\n   - El cliente transfiere fondos desde una cuenta bancaria o de pago de su propia titularidad hacia la cuenta recaudadora de **Cuentas de Orden** del PSAV abierta en la Entidad Financiera Patrocinadora (**Banco Coinag S.A. APIs v4.9 / Banco CMF / Red COELSA**), operando bajo el esquema de salto transaccional de **CVU Corta a CBU Larga Recaudadora** exenta del Impuesto sobre los Créditos y Débitos Bancarios conforme al **Decreto PEN N° 475/2026 y RG ARCA N° 5869/2026**.\n   - El webhook bancario autenticado (`/api/webhooks/sponsor-bank/transferencia`) verifica la regla de **Misma Titularidad (*Same-Name Rule* — BCRA Com. \"A\" 7340 y Art. 18 RG CNV 1058/25)** cotejando el CUIT/CUIL del originante informado por COELSA contra el `cuit_cuil` del legajo del usuario en `public.wallet_users`. Si los CUIT/CUIL no coinciden o provienen de terceros no autorizados, el depósito es rechazado o retenido preventivamente.\n   - El sistema almacena la evidencia forense del movimiento bancario (incluyendo la trama cruda de 180 caracteres en `public.bank_clearing_items.raw_line` durante la conciliación SFTP D-1 de lotes COELSA DEBIN Fase 4 v5.0 y Movimientos PSP 1.1) y acredita el saldo fiduciario en la cuenta `MEMORANDUM_CLIENT` del usuario.\n2. **Ingreso de la Oferta de Compra/Venta y Reserva de Saldo**:\n   - Cuando el cliente instruye la compra (`ARS -> USDT`) o venta (`USDT -> ARS`), el sistema registra la oferta en `public.yohub_orders_book` con `psav_category = 1` y `order_ingested_at = clock_timestamp()`.\n   - Se bloquea pesimistamente la cuenta de origen (`SELECT ... FOR UPDATE`) y se transfiere el monto ofertado de `current_balance` a `locked_balance`.\n3. **Calce contra Proveedor de Liquidez y Liquidación en Partida Doble**:\n   - La orden se ejecuta contra el libro interno o se rutea hacia el proveedor de liquidez institucional regulado (`Bit2Me` — convenio registrado bajo el Art. 35 RG CNV 1058/25 en `public.bcra_third_party_registry`) mediante el patrón *Transactional Outbox*.\n   - Confirmado el calce, dentro de una única transacción atómica PostgreSQL se consume el `locked_balance`, se asientan las partidas de débito y crédito en `public.yohub_ledger_entries` (verificando Suma Cero = 0 en el `transaction_group_id`), y se sella `registered_at = clock_timestamp()` y `record_sha256` en `public.yohub_orders_book`.\n4. **Egreso Fiduciario (Off-Ramp Bancario)**:\n   - En órdenes de venta con retiro fiduciario hacia CBU/CVU externo, el sistema valida previamente la titularidad de la cuenta destino en COELSA y liquida la transferencia inmediata registrando el identificador COELSA/OBID en el asiento contable.\n\n### 3.2. Categoría 2°: Intercambio entre Una o Más Formas de Activos Virtuales (Swap Cripto-a-Cripto)\nComprende las órdenes de conversión directa entre distintos Activos Virtuales (`order_type = 'SWAP'`, `psav_category = 2`, ej. `BTC <-> USDT`, `ETH <-> USDC`):\n1. **Fijación de Cotización Firme y *Quote Locking* Criptográfico (Art. 31)**:\n   - Previo a la confirmación del cliente, el motor de cotizaciones (`/api/wallet/transfer/quote` y `/api/wallet/swap-internal`) consulta el precio en tiempo real del Oráculo institucional y aplica de forma transparente el diferencial (*spread*) máximo parametrizado para el Tenant en `public.corporate_cnv_psav_configs.fee_crypto_swap_max_spread_bps` (Art. 31 RG CNV 1058/25).\n   - El servidor emite un token de cotización firmado con **HMAC-SHA256** que incluye el par (`base_asset`, `quote_asset`), la tasa exacta (`execution_price`), la comisión desglosada (`fee_amount`) y un tiempo de expiración determinista (TTL).\n2. **Prioridad Temporal Estricta FIFO (*First-In, First-Out*) Anti-Front-Running (Arts. 24 inc. e y 26)**:\n   - Las órdenes ingresadas se procesan en estricto orden cronológico de recepción según su marca temporal `order_ingested_at` y su secuencia monótona.\n   - La plataforma no realiza operaciones de *proprietary trading* con ventaja informativa ni reordena colas de ejecución, garantizando neutralidad absoluta y ausencia de *front-running*.\n3. **Asiento Contable Atómico Multi-Pata**:\n   - La función transaccional ejecuta en una sola unidad de trabajo (`BEGIN ... COMMIT`):\n     - Débito del activo entregado (`SWAP_DEBIT`) en la cuenta `MEMORANDUM_CLIENT` del usuario;\n     - Crédito del activo recibido (`SWAP_CREDIT`) en la cuenta `MEMORANDUM_CLIENT` del usuario;\n     - Contrapartida simétrica en las cuentas ómnibus segregadas (`OMNIBUS_MASTER`) de ambos activos;\n     - Imputación de la comisión devengada en la cuenta de resultados del PSAV (`REVENUE_FEE` en el plano `PATRIMONIAL_OWN`).\n   - Se registra la orden en `public.yohub_orders_book` con `psav_category = 2`, `status = 'EXECUTED'` y sello `record_sha256`.\n\n### 3.3. Categoría 3°: Transferencia de Activos Virtuales\nComprende toda instrucción de envío o recepción de Activos Virtuales (`order_type = 'TRANSFER'`, `psav_category = 3`), distinguiendo técnicamente dos modalidades:\n1. **Transferencias Internas entre Clientes en el Libro Mayor (*Off-Chain Book-Entry*)**:\n   - Cuando el destinatario es otro usuario registrado en la infraestructura (`INTERNAL_TRANSFER` o `CROSS_TENANT_TRANSFER`), la liquidación se realiza íntegramente dentro de PostgreSQL mediante la función `rpc_execute_federated_transfer`.\n   - No se incurre en costo de gas de red blockchain (comisión `0.00%` bonificada según Cuadro Tarifario Art. 31), la acreditación es instantánea (sub-segundo) y el movimiento queda asentado simultáneamente en `public.yohub_orders_book` (`psav_category = 3`) y en `public.yohub_ledger_entries`.\n2. **Transferencias Externas hacia o desde Direcciones en la Blockchain (*On-Chain Transfers*)**:\n   - **Cumplimiento Automatizado de la Regla de Viaje (*Travel Rule* — Art. 26 Res. UIF N° 49/2024)**: En toda transferencia cuyo importe en dólares estadounidenses iguale o supere el equivalente a **TRES (3) Salarios Mínimos, Vitales y Móviles (`3 * SMVM`)** —o el umbral paramétrico inferior configurado en `public.yohub_regulatory_parameters`—, el motor exige y persiste en `public.travel_rule_records` los datos completos del originante (`originator_name`, `originator_id_number`), del beneficiario (`beneficiary_name`, `beneficiary_type`), el PSAV/VASP de destino (`beneficiary_vasp_name`), la dirección de billetera (`destination_wallet_address`) y la declaración jurada de titularidad en caso de billeteras auto-custodiadas (*unhosted wallets*, `unhosted_ownership_declared`).\n   - **Compuerta de Lista Blanca Obligatoria con Enfriamiento de 24 Horas (Art. 17 inc. d RG CNV 1058/25)**: Ningún retiro on-chain puede ejecutarse hacia una dirección externa que no se encuentre previamente registrada y verificada en `public.yohub_whitelisted_addresses` para ese `user_id` y `corporate_id`, habiendo transcurrido el período de enfriamiento (*cooldown*) mínimo de **VEINTICUATRO (24) horas** parametrizado en `corporate_cnv_psav_configs.whitelist_cooldown_hours`.\n   - **Paridad Custodial vs. Non-Custodial (Smart Accounts ERC-4337)**: En billeteras de abstracción de cuenta (ERC-4337), el sistema verifica criptográficamente el recibo de ejecución y el `tx_hash` real en el nodo RPC antes de impactar el espejo contable.\n\n### 3.4. Categoría 4°: Custodia y/o Administración de Activos Virtuales\nComprende el resguardo técnico, administración de claves criptográficas, detección de depósitos on-chain (`order_type = 'CUSTODY_DEPOSIT'`, `psav_category = 4`), procesamiento de retiros (`order_type = 'CUSTODY_WITHDRAWAL'`, `psav_category = 4`) y conciliación de reservas:\n1. **Procedimiento Técnico de Detección y Acreditación de Depósitos On-Chain**:\n   - Los servicios de indexación y webhooks autenticados (`/api/webhooks/gateway/[provider]` con validación de firma criptográfica HMAC-SHA512 y control de repetición *anti-replay*) monitorean las direcciones de depósito asignadas.\n   - Para prevenir ataques de reorganización de cadena (*chain reorgs*) o doble gasto, el sistema exige alcanzar el número mínimo de confirmaciones definitivas antes de cambiar el estado a acreditado:\n     - **Red Polygon PoS**: mínimo **64 bloques** confirmados;\n     - **Red Bitcoin Mainnet**: mínimo **3 bloques** minados;\n     - **Red Ethereum Mainnet**: estado de finalidad PoS (**Finalized Checkpoint** >= 2 épocas / 64 slots);\n     - **Red TRON Mainnet (TRC-20)**: mínimo **19 bloques Solidified** confirmados por Super Representantes;\n     - **Redes Ethereum L2 (Arbitrum / Optimism / Base)**: confirmación de lote publicado en L1 (*L1 Batch Finality*).\n   - **Blindaje Anti-Emisión Ficticia (*Agnostic Proof of Deposit Invariant*)**: El trigger de base de datos valida que todo asiento `EXTERNAL_DEPOSIT` posea su prueba criptográfica de depósito verificada (`tx_hash` on-chain o referencia de cámara COELSA); cualquier intento de inyectar saldo sin respaldo arroja la excepción `UNBACKED_DEPOSIT_REJECTED`. Asimismo, el índice único `idx_unique_external_deposit_proof_agnostic` garantiza idempotencia absoluta.\n2. **Política de Custodia Térmica y Segregación en Cuentas de Orden (Arts. 14, 15, 16 y 17)**:\n   - Todos los activos de clientes se contabilizan en el plano `MEMORANDUM_CLIENT`, separados del plano `PATRIMONIAL_OWN`.\n   - La distribución física de los activos en custodia respeta la relación paramétrica auditada en `public.corporate_cnv_psav_configs`:\n     - **Bóveda Fría (*Cold Vault* — HSM / Air-Gapped / MPC)**: mínimo **70%** (`cold_vault_min_pct >= 70`);\n     - **Billetera Tibia (*Warm Wallet*)**: máximo **20%** (`warm_wallet_max_pct <= 20`);\n     - **Billetera Caliente (*Hot Wallet* transaccional)**: máximo **10%** (`hot_wallet_max_pct <= 10`);\n     - Con validación estricta Hot + Warm + Cold = 100%.\n3. **Gobernanza Multifirma por Umbral (Art. 17 inc. c) y Emisión de Retiros vía HSM/MPC**:\n   - Todo retiro o movimiento de tesorería desde custodia cuyo valor equivalente iguale o supere el umbral de seguridad parametrizado (**USD 10.000,00** en `multisig_cold_threshold_usd`) requiere obligatoriamente esquema de firma mancomunada **2-de-3 (`2_OF_3`)** registrado en `public.yohub_multisig_approvals`, con intervención de al menos dos oficiales autorizados bajo Principio de Control Dual (4 Ojos) y autenticación biométrica FIDO2/WebAuthn Level 3 antes de que el módulo HSM/MPC transmita la transacción a la red.\n\n### 3.5. Categoría 5°: Servicios Financieros Relacionados con la Oferta de un Emisor y/o Venta de un Activo Virtual (Colocación Primaria)\nComprende la participación y prestación de servicios financieros vinculados a la emisión o colocación primaria de un Activo Virtual (`order_type = 'PRIMARY_ISSUANCE'`, `psav_category = 5`):\n1. **Debida Diligencia Reforzada del Emisor y Segregación por Emisión**:\n   - Previo a habilitar cualquier proyecto en Categoría 5°, el Comité de Cumplimiento ejecuta la debida diligencia reforzada (KYB, Beneficiarios Finales, auditoría técnica del contrato inteligente y dictamen legal sobre la naturaleza jurídica del token) y requiere aprobación expresa por Acta de Directorio conforme a `category_5_primary_issuance_policy`.\n2. **Validación Previa Obligatoria del Whitepaper Oficial (Art. 37 RG CNV 1058/25)**:\n   - El activo debe encontrarse dado de alta en `public.yohub_products` cumpliendo los once (11) recaudos informativos del Artículo 37: identificación del emisor (`issuer_info`), resumen de riesgos técnicos y económicos (`art37_risk_summary`), fecha de lanzamiento (`launch_date`), enlace público permanente al documento técnico fundacional (`whitepaper_url`) y sello criptográfico de integridad de 64 caracteres hexadecimales (`whitepaper_sha256`).\n   - Cuando la antigüedad del Activo Virtual desde su `launch_date` sea inferior a **NOVENTA (90) días corridos** (`is_under_90_days = true`), la plataforma lo exhibe en una sección segregada con advertencia de riesgo reforzada conforme al último párrafo del Artículo 36.\n   - El trigger `trg_enforce_cat5_security_gate` en `public.yohub_products` y el trigger `trg_immutable_orders_book_art11` en `public.yohub_orders_book` rechazan con la excepción `CAT5_WHITEPAPER_REQUIRED_ART37` cualquier intento de activar un activo o cursar una orden `PRIMARY_ISSUANCE` si `whitepaper_url` o `whitepaper_sha256` (64 chars hex) se encuentran vacíos o incompletos.\n3. **Bloqueo Técnico Determinista de Valores Negociables sin Oferta Pública CNV (Ley N° 26.831 Art. 2)**:\n   - El catálogo de productos incluye el atributo booleano `is_negotiable_security`, el indicador `cnv_public_offering_authorized` y el campo `cnv_offering_resolution`.\n   - Si un activo representa un derecho de crédito, participación societaria, instrumento de deuda soberana/corporativa o contrato de inversión alcanzado por el **Artículo 2° de la Ley N° 26.831** (por ejemplo, el activo `TBILL_RWA` — *Tokenized US T-Bill RWA*, marcado con `is_negotiable_security = true`), **queda bloqueado determinísticamente a nivel de motor de base de datos PostgreSQL** (`is_active = false`, `cat5_primary_issuance_enabled = false`).\n   - El trigger `trg_enforce_cat5_security_gate` impide activar (`is_active = true`) o habilitar la colocación primaria (`cat5_primary_issuance_enabled = true`), y el trigger `trg_immutable_orders_book_art11` impide insertar órdenes sobre dicho activo mientras `cnv_public_offering_authorized` sea `false` o carezca de número de Resolución de Oferta Pública de la CNV (`cnv_offering_resolution`), arrojando de forma inmediata el error `SECURITY_TOKEN_REQUIRES_CNV_PUBLIC_OFFERING_AUTH`.\n\n---\n\n## 4. VALIDACIONES PRE-TRANSACCIONALES Y CONTROL DE CONCURRENCIA\n\n### 4.1. Las Seis (6) Validaciones Automáticas Pre-Transaccionales Síncronas\nNinguna oferta ingresada al sistema puede pasar a ejecución sin superar de manera síncrona y satisfactoria las siguientes seis (6) compuertas automáticas:\n1. **Compuerta 1 — Estado del Legajo KYC/KYB y Listas Restrictivas PLA/FT**: Verificación en `public.wallet_users` y `global_identities.compliance_data.tenant_dossiers[corporate_id]` de que el cliente posee estado `APPROVED` / `VERIFIED_ALL`, sin bloqueos preventivos ni alertas críticas abiertas en `public.compliance_alerts` (RePET, ONU, OFAC, GAFI).\n2. **Compuerta 2 — Aceptación Expresa de la DDJJ de Riesgos (Art. 36) y Términos de Cuentas de Orden (Art. 16)**: Verificación en `public.corporate_legal_acceptances` de que el usuario ha firmado digitalmente la versión vigente de `DDJJ_RIESGOS_ART36` (incisos `a` a `l`) y `TNC_CUENTAS_DE_ORDEN_ART16_18_19`.\n3. **Compuerta 3 — Evaluación del Perfil Transaccional Dinámico Indexado en SMVM (Res. UIF N° 49/2024)**: Invocación a la función PL/pgSQL `public.rpc_evaluate_transactional_profile`, que calcula el monto de la orden en USD y valida que no exceda:\n   - El tope máximo por transacción (`max_per_tx_usd`);\n   - El acumulado móvil de las últimas **24 horas** (`max_daily_usd`);\n   - El acumulado móvil de los últimos **30 días** (`max_monthly_usd` / multiplicador SMVM mensual);\n   - El acumulado móvil de los últimos **365 días** (`max_annual_usd` / multiplicador SMVM anual).\n4. **Compuerta 4 — Disponibilidad de Saldo Libre de Bloqueos e Invariante de Saldo No Negativo (BCRA PSPCP 4.1.2)**: Verificación matemática en precisión `NUMERIC(36, 18)` de que la cuenta de origen posee saldo disponible suficiente (`current_balance - locked_balance >= offered_amount + fee_amount`). El motor tiene prohibido otorgar descubiertos o permitir saldos negativos (`CHECK (current_balance >= 0 AND locked_balance >= 0)`).\n5. **Compuerta 5 — Reglas de Producto, Red, Travel Rule y Whitelist 24h**: Verificación de que el activo permite la dirección del flujo (`default_allow_inbound` / `default_allow_outbound`), que en retiros on-chain la dirección destino cumple las 24 horas de enfriamiento en `yohub_whitelisted_addresses` (Art. 17 inc. d) y que se ha integrado el registro de `travel_rule_records` si el monto es >= 3 SMVM.\n6. **Compuerta 6 — Compuerta de Categoría 5°, Whitepaper Art. 37 e Incompatibilidad Ley 26.831**: Verificación por los triggers `trg_enforce_cat5_security_gate` y `trg_immutable_orders_book_art11` de que el activo posee `whitepaper_sha256` válido y no constituye un Valor Negociable sin autorización de oferta pública de la CNV.\n\n### 4.2. Mecanismo de Bloqueo Transaccional Pesimista y Control de Concurrencia\nPara garantizar atomicidad (`ACID`), aislamiento serializable efectivo sobre saldos y ausencia total de condiciones de carrera (*race conditions*) o interbloqueos (*deadlocks*) bajo alta concurrencia:\n1. **Bloqueo Pesimista con Ordenamiento Lexicográfico Determinista Anti-Deadlock**:\n   - Cuando una operación involucra dos o más cuentas contables (ej. cuenta origen del cliente, cuenta destino, cuenta ómnibus y cuenta de comisiones), el procedimiento almacenado adquiere el bloqueo exclusivo de fila ejecutando:\n     ```sql\n     SELECT id, current_balance, locked_balance\n     FROM public.yohub_accounts\n     WHERE id = ANY(v_account_ids)\n     ORDER BY id ASC\n     FOR UPDATE;\n     ```\n   - Al ordenar los identificadores `UUID` en forma ascendente (`ORDER BY id ASC`) antes de adquirir los cerrojos `FOR UPDATE`, dos transacciones concurrentes cruzadas (ej. Usuario A transfiere a Usuario B al mismo milisegundo en que Usuario B transfiere a Usuario A) solicitan los bloqueos exactamente en el mismo orden canónico, **eliminando matemáticamente la posibilidad de un ciclo de espera (*deadlock*)**.\n2. **Reserva Atómica de Saldo en Tránsito (`locked_balance` — Saga Fase 1)**:\n   - En operaciones asíncronas que dependen de confirmación externa (liquidación en blockchain o cámara compensadora bancaria), la Fase 1 deduce el importe de `current_balance` o lo compromete en `locked_balance` dentro de la misma transacción en que la orden ingresa a `yohub_orders_book` (`status = 'PENDING_SETTLEMENT'`). Si el cliente envía múltiples peticiones simultáneas (*double-click* o ataque de concurrencia), la segunda petición encuentra el cerrojo `FOR UPDATE` y, al liberarse, verifica el saldo ya disminuido, siendo rechazada de inmediato por saldo insuficiente.\n3. **Secuencia Monótona por Cuenta (`account_seq`) e Invariante Diferida de Suma Cero**:\n   - Cada inserción en `public.yohub_ledger_entries` asigna `account_seq = COALESCE(MAX(account_seq), 0) + 1` bajo el cerrojo de la cuenta.\n   - Al finalizar la transacción (`DEFERRABLE INITIALLY DEFERRED`), el constraint trigger `fn_enforce_zero_sum_transaction_group` comprueba que la suma algebraica de todos los movimientos del `transaction_group_id` por moneda sea exactamente igual a cero (`SUM(amount) = 0.000000000000000000`). En caso de discrepancia de siquiera 1e-18 unidades, la transacción completa hace `ROLLBACK` automático.\n","sha256_hash":"SHA256:96BBE0B31094F9FD4C207FF2455039AF0F4026C1EC97D53200714E96A0A6CBB6","board_approval_act":"Acta de Directorio PSAV 2026 — Aprobación Manual Técnico M01 (Art. 11 RG CNV N° 1058/25)","effective_from":"2026-10-16T21:40:40.175651+00:00","is_active":true},{"id":"7f3d8598-8f14-46f3-842c-f3f26668b029","corporate_id":"0608844d-2dbf-48a3-b472-8b00d60d8a67","doc_type":"M01_MANUAL_SISTEMAS_ORDENES_ART11","version_tag":"v2.0-CNV1058-M01","title":"Manual de Procedimientos de Sistemas Informáticos, Tratamiento de Órdenes y Registro Cronológico al Segundo (Art. 11 RG CNV N° 1058/25)","normative_reference":"RG CNV N° 1058/25","summary_markdown":"# MANUAL DE PROCEDIMIENTOS DE SISTEMAS INFORMÁTICOS, TRATAMIENTO DE ÓRDENES Y REGISTRO CRONOLÓGICO AL SEGUNDO (M01)\n## RESOLUCIÓN GENERAL CNV N° 1058/2025 — ARTÍCULO 11 | LEY N° 27.739 | RESOLUCIÓN UIF N° 49/2024\n\n- **Código de Documento**: `M01_MANUAL_SISTEMAS_ORDENES_ART11`\n- **Versión Vigente**: `v2.0-CNV1058-M01` (Producción — Homologación Técnica Área de Sistemas CNV)\n- **Entidad Sujeto Obligado / PSAV**: Configurada por Tenant en `public.corporate_cnv_psav_configs` (incluyendo **DAV NEXT S.A.** — CUIT `30-71960008-1`)\n- **Órgano de Aprobación**: Directorio de la Sociedad — Acta de Directorio Fundacional PSAV 2026\n- **Responsables de Emisión y Control**: Responsable de Cumplimiento Regulatorio y Control Interno (Art. 21 RG CNV N° 1058/25), Oficial de Cumplimiento PLA/FT (Res. UIF N° 49/2024) y Dirección de Tecnología (CTO / Idóneo Informático Art. 20)\n\n---\n\n## 1. ENCUADRE NORMATIVO Y ALCANCE INSTITUCIONAL\n\nEl presente Manual de Procedimientos de Sistemas Informáticos, Tratamiento de Órdenes y Registro Cronológico al Segundo (en adelante, el **\"Manual M01\"**) establece la arquitectura técnica, las estructuras de datos inmutables, los algoritmos de sincronización horaria, los flujos transaccionales para las **Categorías 1° a 5° de Proveedores de Servicios de Activos Virtuales (PSAV)** y los mecanismos de control de concurrencia implementados en producción en el motor transaccional (**Ledger SSOT V5**).\n\nEl diseño e implementación técnica dan cumplimiento estricto y verificable al siguiente plexo normativo de la República Argentina:\n1. **Resolución General CNV N° 1058/2025 (Título XIV, Capítulo III de las Normas de la Comisión Nacional de Valores — T.O. 2013 y mod.)**:\n   - **Artículo 4° y Artículo 4° bis de la Ley N° 25.246 (mod. por Ley N° 27.739)**: Definición y alcance de las Cinco (5) Categorías de servicios sobre Activos Virtuales.\n   - **Artículo 11 (Sistemas Informáticos y Registro Cronológico al Segundo)**: Obligación de contar con sistemas informáticos que permitan registrar en forma cronológica, al segundo y con carácter inalterable, cada oferta ingresada y cada operación registrada con sus seis (6) atributos mínimos obligatorios, así como los procedimientos técnicos aplicables a cada categoría operativa.\n   - **Artículos 14, 15, 16, 17, 18 y 19 (Segregación Patrimonial en Cuentas de Orden, Prueba de Reservas y Custodia)**: Aislamiento matemático entre el patrimonio propio del PSAV (`PATRIMONIAL_OWN`) y los fondos/activos de terceros (`MEMORANDUM_CLIENT`), conciliación 1:1, custodia multifirma y prohibición de disposición de activos de clientes sin consentimiento expreso.\n   - **Artículo 20 (Auditoría Anual de Sistemas Informáticos)**: Trazabilidad criptográfica SHA-256 auditable por profesional independiente con competencia técnica.\n   - **Artículos 24 inc. e), 26 y 31 (Prioridad Temporal FIFO, Prevención de Front-Running y Transparencia Tarifaria)**: Ejecución estricta por orden de prelación temporal y divulgación previa de comisiones y spreads.\n   - **Artículos 36 y 37 (Divulgación de Riesgos al Consumidor y Régimen de Whitepapers)**: Exigencia de aceptación previa de los 12 riesgos regulatorios (incisos `a` a `l`), publicación de fichas técnicas oficiales (*Whitepapers*) con once (11) requisitos mínimos y advertencia destacada para Activos Virtuales con antigüedad inferior a NOVENTA (90) días corridos.\n   - **Artículo 38 (Conservación de la Documentación e Inmutabilidad por 10 Años)**: Preservación íntegra bajo modalidad *Write-Once-Read-Many* (WORM) durante un plazo mínimo de DIEZ (10) años.\n2. **Ley N° 26.831 de Mercado de Capitales (Artículo 2°)**: Delimitación e incompatibilidad técnica automática respecto de Activos Virtuales que constituyan **Valores Negociables** o contratos de inversión, los cuales se encuentran bloqueados a nivel motor de base de datos salvo autorización expresa de Oferta Pública otorgada por la CNV.\n3. **Resolución UIF N° 49/2024**: Régimen de Prevención de Lavado de Activos y Financiación del Terrorismo (PLA/FT/FPADM) para PSAV, incluyendo Perfil Transaccional Dinámico indexado en Salarios Mínimos, Vitales y Móviles (SMVM), monitoreo automatizado y cumplimiento de la Regla de Viaje (*Travel Rule* >= 3 SMVM).\n4. **Comunicaciones Técnicas del BCRA (Marco 2026 para Rieles Fiduciarios y PSPCP)**: Comunicaciones \"A\" 8406 (CIMPRA), \"A\" 8411 (Balance Cero diario con sellado Merkle), \"A\" 8469 (Cuentas Puente de Recaudación Suma Cero), \"A\" 8473 (Gobernanza Anti-Fraude e Interoperabilidad) y Punto 4.1.2 del T.O. de PSPCP (Invariante de Saldo No Negativo).\n\n---\n\n## 2. ESTRUCTURA DEL REGISTRO Y PRESERVACIÓN DE DATOS (ART. 11 PÁRRAFO 1°)\n\n### 2.1. Esquema Relacional del Libro de Órdenes (`public.yohub_orders_book`) y Libro Mayor (`public.yohub_ledger_entries`)\nEl sistema preserva de manera permanente e inalterable la totalidad de las ofertas ingresadas por los clientes y las operaciones liquidadas en dos estructuras relacionales vinculadas atómicamente en PostgreSQL:\n- **`public.yohub_orders_book` (Libro Electrónico de Ofertas y Órdenes — Art. 11)**: Registra el ciclo de vida completo de cada instrucción desde el microsegundo exacto de su recepción (`order_ingested_at`) hasta su ejecución y liquidación (`registered_at`).\n- **`public.yohub_ledger_entries` (Libro Mayor de Partida Doble — Arts. 15, 16 y 20)**: Registra los asientos contables atómicos en planos segregados asociados mediante `transaction_group_id`.\n\nA continuación se detalla el mapeo campo por campo de los **SEIS (6) datos mínimos obligatorios exigidos por el Artículo 11 párrafo 1° de la RG CNV N° 1058/25**:\n\n| N° | Requisito Normativo (Art. 11 párr. 1° RG 1058/25) | Columna en `public.yohub_orders_book` | Columna en `public.yohub_ledger_entries` | Tipo de Dato y Restricción en Motor PostgreSQL |\n| :--- | :--- | :--- | :--- | :--- |\n| **1** | **Fecha, hora, minutos y segundos en que ingresaron como ofertas al sistema** | `order_ingested_at` | `order_ingested_at` | `TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp()` — Capturado en el instante de ingreso de la oferta a la API BFF. |\n| **2** | **Fecha, hora, minutos y segundos en que fueron registradas en el sistema** | `registered_at` | `settled_at` / `created_at` | `TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp()` — Invariante controlada por trigger: `registered_at >= order_ingested_at`. |\n| **3** | **Cantidad ofertada (para compra y/o venta, conversión, transferencia o custodia)** | `offered_amount`, `executed_amount`, `execution_price`, `fee_amount`, `order_type`, `psav_category` | `amount`, `amount_usd`, `fx_rate_usd`, `entry_type` | `NUMERIC(36, 18) NOT NULL` — Cero punto flotante. Categoría PSAV `SMALLINT CHECK (psav_category BETWEEN 1 AND 5)`. |\n| **4** | **Tipo de Activo Virtual (AV)** | `base_asset`, `quote_asset` | `currency` | `VARCHAR NOT NULL` — Validado contra catálogo maestro `public.yohub_products.symbol` (ej. `BTC`, `ETH`, `USDT`, `USDC`, `DAI`, `TRX`, `ARS`, `USD`). |\n| **5** | **Identificador interno o código HASH en caso de haber sido registrada en blockchain** | `order_id` (PK), `transaction_group_id`, `blockchain_tx_hash`, `record_sha256` | `entry_id` (PK), `transaction_group_id`, `account_seq`, `tx_hash`, `prev_hash`, `current_hash` | `UUID v4` para identificadores internos, `BIGINT` monótono para `account_seq`, `TEXT` para `TXID` on-chain y `VARCHAR(64)` para sello SHA-256. |\n| **6** | **Identificación del cliente (Persona Humana o Persona Jurídica)** | `user_id`, `client_tax_id`, `client_person_type` | `account_id -> yohub_accounts.user_id` | `UUID v4 NOT NULL` FK a `public.wallet_users(id)`, `client_tax_id VARCHAR(32)` (CUIT/CUIL/DNI) y `client_person_type VARCHAR(20)` (`'HUMANA'` / `'JURIDICA'`). |\n\n### 2.2. Sincronización Horaria Atómica (Protocolo NTP Estrato 1 y Estándar ISO 8601 UTC-3)\n1. **Fuente de Tiempo Oficial (`ntp_sync_source`)**: Todos los nodos de aplicación y el clúster de base de datos sincronizan su reloj del sistema mediante el protocolo **NTP (Network Time Protocol) Estrato 1** provisto por **AWS Time Sync Service (`169.254.169.123`)**, conectado a una flota de relojes atómicos de Cesio y receptores satelitales GPS redundantes, con desviación máxima controlada inferior a 1 milisegundo (< 1 ms).\n2. **Estampado al Microsegundo en Motor Transaccional**: A diferencia de la función `now()` (que congela el tiempo al inicio del bloque transaccional), los procedimientos almacenados y triggers del Libro de Órdenes y del Libro Mayor invocan **`clock_timestamp()`**, capturando el tiempo real de reloj de pared con resolución de microsegundos.\n3. **Representación y Huso Horario Oficial Argentino**: Los registros se almacenan en tipo `TIMESTAMPTZ` (UTC absoluto con desplazamiento horario) y se exponen en todas las APIs regulatorias, reportes TAD y consolas de auditoría en formato estándar **ISO 8601 (`YYYY-MM-DDTHH:mm:ss.sss-03:00`)** bajo el huso horario oficial de la República Argentina (**`America/Argentina/Buenos_Aires` — UTC-3**).\n4. **Invariante de Prelación Cronológica**: El trigger `trg_immutable_orders_book_art11` verifica en cada inserción o actualización de estado que `NEW.registered_at >= NEW.order_ingested_at`. Cualquier intento de registrar una ejecución con marca temporal anterior al ingreso de la oferta es abortado inmediatamente con la excepción `CHRONOLOGICAL_ORDER_VIOLATION_ART11`.\n\n### 2.3. Precisión Decimal Exacta y Trazabilidad de Identificadores\n1. **Prohibición Absoluta de Punto Flootante**: Queda estrictamente prohibido en toda la arquitectura el uso de tipos `FLOAT`, `REAL`, `DOUBLE PRECISION` en SQL o `parseFloat()` / `Number()` en TypeScript para cálculos monetarios.\n   - **Base de Datos (PostgreSQL)**: Todos los importes (`offered_amount`, `executed_amount`, `execution_price`, `fee_amount`, `amount`, `current_balance`, `locked_balance`) utilizan `NUMERIC(36, 18)`.\n   - **Capa BFF / Servicios (Node.js / TypeScript)**: Toda la aritmética financiera y de conversión se procesa con la librería **`Decimal.js`** configurada con `precision: 36` y redondeo determinista `Decimal.ROUND_DOWN` bajo el contrato de precisión `v2_strict_decimal`.\n   - **Capa Cliente**: Los importes se serializan como cadenas de texto (`string`) o enteros de precisión arbitraria (`BigInt`) expresados en unidades atómicas (*wei*, *satoshis*, centavos).\n2. **Asociación Unívoca con Identificadores Internos y Hashes de Blockchain**:\n   - Cada oferta recibe al ingresar un `order_id` (`UUID v4`) único.\n   - Al ejecutarse contablemente, se vincula de forma inmutable con un `transaction_group_id` (`UUID v4`) que agrupa todas las patas de partida doble en `public.yohub_ledger_entries`.\n   - Cada cuenta afectada incrementa su número de secuencia estrictamente monótono (`account_seq BIGINT`), impidiendo intercalar o reordenar operaciones históricas.\n   - En operaciones con liquidación en redes distribuidas (Categorías 3° y 4°), el campo `blockchain_tx_hash` (en `yohub_orders_book`) y `tx_hash` (en `yohub_ledger_entries`) almacena el identificador criptográfico de la transacción en la blockchain (`TXID` de 64 caracteres hexadecimales), protegido por el índice único `idx_unique_external_deposit_proof_agnostic` para impedir la doble acreditación de un mismo evento on-chain.\n\n### 2.4. Vinculación con el Legajo KYC/KYB del Cliente (Persona Humana y Persona Jurídica)\nNinguna orden puede existir de forma anónima ni disociada de su titular verificado:\n1. Toda fila en `public.yohub_orders_book` posee clave foránea obligatoria (`NOT NULL`) hacia `public.wallet_users(id)` y hacia la entidad PSAV `public.corporates(id)` (`corporate_id`).\n2. Al momento de la inserción, el trigger `fn_immutable_orders_book_art11()` consulta `public.wallet_users` y estampa de forma inmutable en la propia fila de la orden:\n   - `client_tax_id`: El número de **CUIT, CUIL o DNI** del cliente (`COALESCE(wu.cuit_cuil, wu.id_number)`).\n   - `client_person_type`: La clasificación jurídica del titular (`'HUMANA'` o `'JURIDICA'`) tomada de `wallet_users.person_type`.\n3. **Trazabilidad hacia el Legajo Documental Aislado por Sujeto Obligado**:\n   - **Personas Humanas (`client_person_type = 'HUMANA'`)**: El `user_id` enlaza con `public.global_identities`, cuyo atributo `compliance_data -> 'tenant_dossiers' -> [corporate_id]` conserva el legajo de Debida Diligencia del Cliente (biometría facial Didit v3 / Sumsub, prueba de vida, validación RENAPER, declaración jurada PEP, sujeto obligado UIF, residencia fiscal CRS/FATCA y resultado de cribado en listas RePET, ONU y OFAC).\n   - **Personas Jurídicas (`client_person_type = 'JURIDICA'`)**: El registro enlaza adicionalmente con `public.b2b_entities`, donde obran el estatuto social, acta de designación de autoridades, registro de Beneficiarios Finales (>= 10% de participación conforme Res. UIF N° 49/2024), inscripción AFIP/ARCA y poderes de los representantes legales autorizados a operar.\n\n### 2.5. Mecanismos de Inmutabilidad Criptográfica WORM y Conservación por 10 Años (Art. 38)\nPara garantizar que ninguna oferta ingresada ni operación registrada pueda ser alterada, sobrescrita o eliminada física o lógicamente durante el plazo legal mínimo de **DIEZ (10) años** (Art. 38 RG CNV N° 1058/25), la base de datos implementa tres anillos de defensa criptográfica a nivel de motor PostgreSQL:\n1. **Trigger WORM en el Libro de Órdenes (`trg_immutable_orders_book_art11`)**:\n   - Intercepta cualquier sentencia `DELETE` sobre `public.yohub_orders_book` y aborta la transacción arrojando la excepción `ART11_RG1058_DELETE_FORBIDDEN`.\n   - Intercepta cualquier sentencia `UPDATE` que intente modificar los atributos originales de la oferta (`order_id`, `corporate_id`, `user_id`, `order_type`, `psav_category`, `base_asset`, `quote_asset`, `offered_amount`, `order_ingested_at`, `client_tax_id`, `client_person_type`), abortando la transacción con `ART11_RG1058_IMMUTABILITY_VIOLATION`. Únicamente se permite la transición controlada de `status`, `executed_amount`, `registered_at`, `transaction_group_id` y `blockchain_tx_hash` cuando una orden en tránsito pasa a estado final liquidado.\n   - Calcula y sella en la columna `record_sha256` el digest criptográfico `SHA-256` (`extensions.digest(..., 'sha256')`) sobre la concatenación canónica de todos los atributos de la orden.\n2. **Trigger WORM y Cadena de Bloques Interna en el Libro Mayor (`trg_immutable_ledger_entries`)**:\n   - Prohíbe en forma absoluta cualquier `UPDATE` o `DELETE` sobre `public.yohub_ledger_entries`. Cualquier ajuste contable o reversa debe instrumentarse exclusivamente mediante un nuevo asiento compensatorio de partida doble (`CLEARING_ADJUSTMENT` o `REVERSAL`) vinculado al asiento original mediante `parent_entry_id` y `root_transaction_group_id`.\n   - Cada asiento incorpora en su cálculo de `current_hash` (`SHA-256`) el hash exacto del asiento inmediato anterior de la misma cuenta (`prev_hash`), formando una estructura encadenada donde la alteración de un solo bit histórico invalidaría toda la cadena subsiguiente.\n3. **Sellado Diario de Árbol de Merkle (`public.bcra_daily_ledger_seals`)**:\n   - Al cierre de cada jornada operativa, el motor consolida los hashes de todas las operaciones y saldos de Cuentas de Orden en una Raíz de Merkle (`merkle_root_hash` SHA-256), la cual queda asentada y disponible para verificación pública en `/api/cnv/proof-of-reserves` y `/cnv-transparencia`.\n\n---\n\n## 3. PROCEDIMIENTOS TÉCNICOS DE TRATAMIENTO DE ÓRDENES POR CATEGORÍA (ART. 11 PÁRRAFO 2° — CATEGORÍAS 1° A 5°)\n\nDe conformidad con el segundo párrafo del Artículo 11 de la RG CNV N° 1058/25 y el Artículo 4° bis de la Ley N° 25.246, se detallan a continuación los procedimientos técnicos de procesamiento para cada una de las cinco (5) categorías operativas:\n\n### 3.1. Categoría 1°: Intercambio entre Activos Virtuales y Monedas de Curso Legal (Monedas Fiduciarias ARS / USD)\nComprende las órdenes de compra (`order_type = 'BUY'`, `psav_category = 1`) y venta (`order_type = 'SELL'`, `psav_category = 1`) de Activos Virtuales contra Pesos Argentinos (`ARS`) o Dólares Estadounidenses (`USD`):\n1. **Ingreso y Conciliación de Fondos Fiduciarios (In-Ramp Bancario)**:\n   - El cliente transfiere fondos desde una cuenta bancaria o de pago de su propia titularidad hacia la cuenta recaudadora de **Cuentas de Orden** del PSAV abierta en la Entidad Financiera Patrocinadora (**Banco Coinag S.A. APIs v4.9 / Banco CMF / Red COELSA**), operando bajo el esquema de salto transaccional de **CVU Corta a CBU Larga Recaudadora** exenta del Impuesto sobre los Créditos y Débitos Bancarios conforme al **Decreto PEN N° 475/2026 y RG ARCA N° 5869/2026**.\n   - El webhook bancario autenticado (`/api/webhooks/sponsor-bank/transferencia`) verifica la regla de **Misma Titularidad (*Same-Name Rule* — BCRA Com. \"A\" 7340 y Art. 18 RG CNV 1058/25)** cotejando el CUIT/CUIL del originante informado por COELSA contra el `cuit_cuil` del legajo del usuario en `public.wallet_users`. Si los CUIT/CUIL no coinciden o provienen de terceros no autorizados, el depósito es rechazado o retenido preventivamente.\n   - El sistema almacena la evidencia forense del movimiento bancario (incluyendo la trama cruda de 180 caracteres en `public.bank_clearing_items.raw_line` durante la conciliación SFTP D-1 de lotes COELSA DEBIN Fase 4 v5.0 y Movimientos PSP 1.1) y acredita el saldo fiduciario en la cuenta `MEMORANDUM_CLIENT` del usuario.\n2. **Ingreso de la Oferta de Compra/Venta y Reserva de Saldo**:\n   - Cuando el cliente instruye la compra (`ARS -> USDT`) o venta (`USDT -> ARS`), el sistema registra la oferta en `public.yohub_orders_book` con `psav_category = 1` y `order_ingested_at = clock_timestamp()`.\n   - Se bloquea pesimistamente la cuenta de origen (`SELECT ... FOR UPDATE`) y se transfiere el monto ofertado de `current_balance` a `locked_balance`.\n3. **Calce contra Proveedor de Liquidez y Liquidación en Partida Doble**:\n   - La orden se ejecuta contra el libro interno o se rutea hacia el proveedor de liquidez institucional regulado (`Bit2Me` — convenio registrado bajo el Art. 35 RG CNV 1058/25 en `public.bcra_third_party_registry`) mediante el patrón *Transactional Outbox*.\n   - Confirmado el calce, dentro de una única transacción atómica PostgreSQL se consume el `locked_balance`, se asientan las partidas de débito y crédito en `public.yohub_ledger_entries` (verificando Suma Cero = 0 en el `transaction_group_id`), y se sella `registered_at = clock_timestamp()` y `record_sha256` en `public.yohub_orders_book`.\n4. **Egreso Fiduciario (Off-Ramp Bancario)**:\n   - En órdenes de venta con retiro fiduciario hacia CBU/CVU externo, el sistema valida previamente la titularidad de la cuenta destino en COELSA y liquida la transferencia inmediata registrando el identificador COELSA/OBID en el asiento contable.\n\n### 3.2. Categoría 2°: Intercambio entre Una o Más Formas de Activos Virtuales (Swap Cripto-a-Cripto)\nComprende las órdenes de conversión directa entre distintos Activos Virtuales (`order_type = 'SWAP'`, `psav_category = 2`, ej. `BTC <-> USDT`, `ETH <-> USDC`):\n1. **Fijación de Cotización Firme y *Quote Locking* Criptográfico (Art. 31)**:\n   - Previo a la confirmación del cliente, el motor de cotizaciones (`/api/wallet/transfer/quote` y `/api/wallet/swap-internal`) consulta el precio en tiempo real del Oráculo institucional y aplica de forma transparente el diferencial (*spread*) máximo parametrizado para el Tenant en `public.corporate_cnv_psav_configs.fee_crypto_swap_max_spread_bps` (Art. 31 RG CNV 1058/25).\n   - El servidor emite un token de cotización firmado con **HMAC-SHA256** que incluye el par (`base_asset`, `quote_asset`), la tasa exacta (`execution_price`), la comisión desglosada (`fee_amount`) y un tiempo de expiración determinista (TTL).\n2. **Prioridad Temporal Estricta FIFO (*First-In, First-Out*) Anti-Front-Running (Arts. 24 inc. e y 26)**:\n   - Las órdenes ingresadas se procesan en estricto orden cronológico de recepción según su marca temporal `order_ingested_at` y su secuencia monótona.\n   - La plataforma no realiza operaciones de *proprietary trading* con ventaja informativa ni reordena colas de ejecución, garantizando neutralidad absoluta y ausencia de *front-running*.\n3. **Asiento Contable Atómico Multi-Pata**:\n   - La función transaccional ejecuta en una sola unidad de trabajo (`BEGIN ... COMMIT`):\n     - Débito del activo entregado (`SWAP_DEBIT`) en la cuenta `MEMORANDUM_CLIENT` del usuario;\n     - Crédito del activo recibido (`SWAP_CREDIT`) en la cuenta `MEMORANDUM_CLIENT` del usuario;\n     - Contrapartida simétrica en las cuentas ómnibus segregadas (`OMNIBUS_MASTER`) de ambos activos;\n     - Imputación de la comisión devengada en la cuenta de resultados del PSAV (`REVENUE_FEE` en el plano `PATRIMONIAL_OWN`).\n   - Se registra la orden en `public.yohub_orders_book` con `psav_category = 2`, `status = 'EXECUTED'` y sello `record_sha256`.\n\n### 3.3. Categoría 3°: Transferencia de Activos Virtuales\nComprende toda instrucción de envío o recepción de Activos Virtuales (`order_type = 'TRANSFER'`, `psav_category = 3`), distinguiendo técnicamente dos modalidades:\n1. **Transferencias Internas entre Clientes en el Libro Mayor (*Off-Chain Book-Entry*)**:\n   - Cuando el destinatario es otro usuario registrado en la infraestructura (`INTERNAL_TRANSFER` o `CROSS_TENANT_TRANSFER`), la liquidación se realiza íntegramente dentro de PostgreSQL mediante la función `rpc_execute_federated_transfer`.\n   - No se incurre en costo de gas de red blockchain (comisión `0.00%` bonificada según Cuadro Tarifario Art. 31), la acreditación es instantánea (sub-segundo) y el movimiento queda asentado simultáneamente en `public.yohub_orders_book` (`psav_category = 3`) y en `public.yohub_ledger_entries`.\n2. **Transferencias Externas hacia o desde Direcciones en la Blockchain (*On-Chain Transfers*)**:\n   - **Cumplimiento Automatizado de la Regla de Viaje (*Travel Rule* — Art. 26 Res. UIF N° 49/2024)**: En toda transferencia cuyo importe en dólares estadounidenses iguale o supere el equivalente a **TRES (3) Salarios Mínimos, Vitales y Móviles (`3 * SMVM`)** —o el umbral paramétrico inferior configurado en `public.yohub_regulatory_parameters`—, el motor exige y persiste en `public.travel_rule_records` los datos completos del originante (`originator_name`, `originator_id_number`), del beneficiario (`beneficiary_name`, `beneficiary_type`), el PSAV/VASP de destino (`beneficiary_vasp_name`), la dirección de billetera (`destination_wallet_address`) y la declaración jurada de titularidad en caso de billeteras auto-custodiadas (*unhosted wallets*, `unhosted_ownership_declared`).\n   - **Compuerta de Lista Blanca Obligatoria con Enfriamiento de 24 Horas (Art. 17 inc. d RG CNV 1058/25)**: Ningún retiro on-chain puede ejecutarse hacia una dirección externa que no se encuentre previamente registrada y verificada en `public.yohub_whitelisted_addresses` para ese `user_id` y `corporate_id`, habiendo transcurrido el período de enfriamiento (*cooldown*) mínimo de **VEINTICUATRO (24) horas** parametrizado en `corporate_cnv_psav_configs.whitelist_cooldown_hours`.\n   - **Paridad Custodial vs. Non-Custodial (Smart Accounts ERC-4337)**: En billeteras de abstracción de cuenta (ERC-4337), el sistema verifica criptográficamente el recibo de ejecución y el `tx_hash` real en el nodo RPC antes de impactar el espejo contable.\n\n### 3.4. Categoría 4°: Custodia y/o Administración de Activos Virtuales\nComprende el resguardo técnico, administración de claves criptográficas, detección de depósitos on-chain (`order_type = 'CUSTODY_DEPOSIT'`, `psav_category = 4`), procesamiento de retiros (`order_type = 'CUSTODY_WITHDRAWAL'`, `psav_category = 4`) y conciliación de reservas:\n1. **Procedimiento Técnico de Detección y Acreditación de Depósitos On-Chain**:\n   - Los servicios de indexación y webhooks autenticados (`/api/webhooks/gateway/[provider]` con validación de firma criptográfica HMAC-SHA512 y control de repetición *anti-replay*) monitorean las direcciones de depósito asignadas.\n   - Para prevenir ataques de reorganización de cadena (*chain reorgs*) o doble gasto, el sistema exige alcanzar el número mínimo de confirmaciones definitivas antes de cambiar el estado a acreditado:\n     - **Red Polygon PoS**: mínimo **64 bloques** confirmados;\n     - **Red Bitcoin Mainnet**: mínimo **3 bloques** minados;\n     - **Red Ethereum Mainnet**: estado de finalidad PoS (**Finalized Checkpoint** >= 2 épocas / 64 slots);\n     - **Red TRON Mainnet (TRC-20)**: mínimo **19 bloques Solidified** confirmados por Super Representantes;\n     - **Redes Ethereum L2 (Arbitrum / Optimism / Base)**: confirmación de lote publicado en L1 (*L1 Batch Finality*).\n   - **Blindaje Anti-Emisión Ficticia (*Agnostic Proof of Deposit Invariant*)**: El trigger de base de datos valida que todo asiento `EXTERNAL_DEPOSIT` posea su prueba criptográfica de depósito verificada (`tx_hash` on-chain o referencia de cámara COELSA); cualquier intento de inyectar saldo sin respaldo arroja la excepción `UNBACKED_DEPOSIT_REJECTED`. Asimismo, el índice único `idx_unique_external_deposit_proof_agnostic` garantiza idempotencia absoluta.\n2. **Política de Custodia Térmica y Segregación en Cuentas de Orden (Arts. 14, 15, 16 y 17)**:\n   - Todos los activos de clientes se contabilizan en el plano `MEMORANDUM_CLIENT`, separados del plano `PATRIMONIAL_OWN`.\n   - La distribución física de los activos en custodia respeta la relación paramétrica auditada en `public.corporate_cnv_psav_configs`:\n     - **Bóveda Fría (*Cold Vault* — HSM / Air-Gapped / MPC)**: mínimo **70%** (`cold_vault_min_pct >= 70`);\n     - **Billetera Tibia (*Warm Wallet*)**: máximo **20%** (`warm_wallet_max_pct <= 20`);\n     - **Billetera Caliente (*Hot Wallet* transaccional)**: máximo **10%** (`hot_wallet_max_pct <= 10`);\n     - Con validación estricta Hot + Warm + Cold = 100%.\n3. **Gobernanza Multifirma por Umbral (Art. 17 inc. c) y Emisión de Retiros vía HSM/MPC**:\n   - Todo retiro o movimiento de tesorería desde custodia cuyo valor equivalente iguale o supere el umbral de seguridad parametrizado (**USD 10.000,00** en `multisig_cold_threshold_usd`) requiere obligatoriamente esquema de firma mancomunada **2-de-3 (`2_OF_3`)** registrado en `public.yohub_multisig_approvals`, con intervención de al menos dos oficiales autorizados bajo Principio de Control Dual (4 Ojos) y autenticación biométrica FIDO2/WebAuthn Level 3 antes de que el módulo HSM/MPC transmita la transacción a la red.\n\n### 3.5. Categoría 5°: Servicios Financieros Relacionados con la Oferta de un Emisor y/o Venta de un Activo Virtual (Colocación Primaria)\nComprende la participación y prestación de servicios financieros vinculados a la emisión o colocación primaria de un Activo Virtual (`order_type = 'PRIMARY_ISSUANCE'`, `psav_category = 5`):\n1. **Debida Diligencia Reforzada del Emisor y Segregación por Emisión**:\n   - Previo a habilitar cualquier proyecto en Categoría 5°, el Comité de Cumplimiento ejecuta la debida diligencia reforzada (KYB, Beneficiarios Finales, auditoría técnica del contrato inteligente y dictamen legal sobre la naturaleza jurídica del token) y requiere aprobación expresa por Acta de Directorio conforme a `category_5_primary_issuance_policy`.\n2. **Validación Previa Obligatoria del Whitepaper Oficial (Art. 37 RG CNV 1058/25)**:\n   - El activo debe encontrarse dado de alta en `public.yohub_products` cumpliendo los once (11) recaudos informativos del Artículo 37: identificación del emisor (`issuer_info`), resumen de riesgos técnicos y económicos (`art37_risk_summary`), fecha de lanzamiento (`launch_date`), enlace público permanente al documento técnico fundacional (`whitepaper_url`) y sello criptográfico de integridad de 64 caracteres hexadecimales (`whitepaper_sha256`).\n   - Cuando la antigüedad del Activo Virtual desde su `launch_date` sea inferior a **NOVENTA (90) días corridos** (`is_under_90_days = true`), la plataforma lo exhibe en una sección segregada con advertencia de riesgo reforzada conforme al último párrafo del Artículo 36.\n   - El trigger `trg_enforce_cat5_security_gate` en `public.yohub_products` y el trigger `trg_immutable_orders_book_art11` en `public.yohub_orders_book` rechazan con la excepción `CAT5_WHITEPAPER_REQUIRED_ART37` cualquier intento de activar un activo o cursar una orden `PRIMARY_ISSUANCE` si `whitepaper_url` o `whitepaper_sha256` (64 chars hex) se encuentran vacíos o incompletos.\n3. **Bloqueo Técnico Determinista de Valores Negociables sin Oferta Pública CNV (Ley N° 26.831 Art. 2)**:\n   - El catálogo de productos incluye el atributo booleano `is_negotiable_security`, el indicador `cnv_public_offering_authorized` y el campo `cnv_offering_resolution`.\n   - Si un activo representa un derecho de crédito, participación societaria, instrumento de deuda soberana/corporativa o contrato de inversión alcanzado por el **Artículo 2° de la Ley N° 26.831** (por ejemplo, el activo `TBILL_RWA` — *Tokenized US T-Bill RWA*, marcado con `is_negotiable_security = true`), **queda bloqueado determinísticamente a nivel de motor de base de datos PostgreSQL** (`is_active = false`, `cat5_primary_issuance_enabled = false`).\n   - El trigger `trg_enforce_cat5_security_gate` impide activar (`is_active = true`) o habilitar la colocación primaria (`cat5_primary_issuance_enabled = true`), y el trigger `trg_immutable_orders_book_art11` impide insertar órdenes sobre dicho activo mientras `cnv_public_offering_authorized` sea `false` o carezca de número de Resolución de Oferta Pública de la CNV (`cnv_offering_resolution`), arrojando de forma inmediata el error `SECURITY_TOKEN_REQUIRES_CNV_PUBLIC_OFFERING_AUTH`.\n\n---\n\n## 4. VALIDACIONES PRE-TRANSACCIONALES Y CONTROL DE CONCURRENCIA\n\n### 4.1. Las Seis (6) Validaciones Automáticas Pre-Transaccionales Síncronas\nNinguna oferta ingresada al sistema puede pasar a ejecución sin superar de manera síncrona y satisfactoria las siguientes seis (6) compuertas automáticas:\n1. **Compuerta 1 — Estado del Legajo KYC/KYB y Listas Restrictivas PLA/FT**: Verificación en `public.wallet_users` y `global_identities.compliance_data.tenant_dossiers[corporate_id]` de que el cliente posee estado `APPROVED` / `VERIFIED_ALL`, sin bloqueos preventivos ni alertas críticas abiertas en `public.compliance_alerts` (RePET, ONU, OFAC, GAFI).\n2. **Compuerta 2 — Aceptación Expresa de la DDJJ de Riesgos (Art. 36) y Términos de Cuentas de Orden (Art. 16)**: Verificación en `public.corporate_legal_acceptances` de que el usuario ha firmado digitalmente la versión vigente de `DDJJ_RIESGOS_ART36` (incisos `a` a `l`) y `TNC_CUENTAS_DE_ORDEN_ART16_18_19`.\n3. **Compuerta 3 — Evaluación del Perfil Transaccional Dinámico Indexado en SMVM (Res. UIF N° 49/2024)**: Invocación a la función PL/pgSQL `public.rpc_evaluate_transactional_profile`, que calcula el monto de la orden en USD y valida que no exceda:\n   - El tope máximo por transacción (`max_per_tx_usd`);\n   - El acumulado móvil de las últimas **24 horas** (`max_daily_usd`);\n   - El acumulado móvil de los últimos **30 días** (`max_monthly_usd` / multiplicador SMVM mensual);\n   - El acumulado móvil de los últimos **365 días** (`max_annual_usd` / multiplicador SMVM anual).\n4. **Compuerta 4 — Disponibilidad de Saldo Libre de Bloqueos e Invariante de Saldo No Negativo (BCRA PSPCP 4.1.2)**: Verificación matemática en precisión `NUMERIC(36, 18)` de que la cuenta de origen posee saldo disponible suficiente (`current_balance - locked_balance >= offered_amount + fee_amount`). El motor tiene prohibido otorgar descubiertos o permitir saldos negativos (`CHECK (current_balance >= 0 AND locked_balance >= 0)`).\n5. **Compuerta 5 — Reglas de Producto, Red, Travel Rule y Whitelist 24h**: Verificación de que el activo permite la dirección del flujo (`default_allow_inbound` / `default_allow_outbound`), que en retiros on-chain la dirección destino cumple las 24 horas de enfriamiento en `yohub_whitelisted_addresses` (Art. 17 inc. d) y que se ha integrado el registro de `travel_rule_records` si el monto es >= 3 SMVM.\n6. **Compuerta 6 — Compuerta de Categoría 5°, Whitepaper Art. 37 e Incompatibilidad Ley 26.831**: Verificación por los triggers `trg_enforce_cat5_security_gate` y `trg_immutable_orders_book_art11` de que el activo posee `whitepaper_sha256` válido y no constituye un Valor Negociable sin autorización de oferta pública de la CNV.\n\n### 4.2. Mecanismo de Bloqueo Transaccional Pesimista y Control de Concurrencia\nPara garantizar atomicidad (`ACID`), aislamiento serializable efectivo sobre saldos y ausencia total de condiciones de carrera (*race conditions*) o interbloqueos (*deadlocks*) bajo alta concurrencia:\n1. **Bloqueo Pesimista con Ordenamiento Lexicográfico Determinista Anti-Deadlock**:\n   - Cuando una operación involucra dos o más cuentas contables (ej. cuenta origen del cliente, cuenta destino, cuenta ómnibus y cuenta de comisiones), el procedimiento almacenado adquiere el bloqueo exclusivo de fila ejecutando:\n     ```sql\n     SELECT id, current_balance, locked_balance\n     FROM public.yohub_accounts\n     WHERE id = ANY(v_account_ids)\n     ORDER BY id ASC\n     FOR UPDATE;\n     ```\n   - Al ordenar los identificadores `UUID` en forma ascendente (`ORDER BY id ASC`) antes de adquirir los cerrojos `FOR UPDATE`, dos transacciones concurrentes cruzadas (ej. Usuario A transfiere a Usuario B al mismo milisegundo en que Usuario B transfiere a Usuario A) solicitan los bloqueos exactamente en el mismo orden canónico, **eliminando matemáticamente la posibilidad de un ciclo de espera (*deadlock*)**.\n2. **Reserva Atómica de Saldo en Tránsito (`locked_balance` — Saga Fase 1)**:\n   - En operaciones asíncronas que dependen de confirmación externa (liquidación en blockchain o cámara compensadora bancaria), la Fase 1 deduce el importe de `current_balance` o lo compromete en `locked_balance` dentro de la misma transacción en que la orden ingresa a `yohub_orders_book` (`status = 'PENDING_SETTLEMENT'`). Si el cliente envía múltiples peticiones simultáneas (*double-click* o ataque de concurrencia), la segunda petición encuentra el cerrojo `FOR UPDATE` y, al liberarse, verifica el saldo ya disminuido, siendo rechazada de inmediato por saldo insuficiente.\n3. **Secuencia Monótona por Cuenta (`account_seq`) e Invariante Diferida de Suma Cero**:\n   - Cada inserción en `public.yohub_ledger_entries` asigna `account_seq = COALESCE(MAX(account_seq), 0) + 1` bajo el cerrojo de la cuenta.\n   - Al finalizar la transacción (`DEFERRABLE INITIALLY DEFERRED`), el constraint trigger `fn_enforce_zero_sum_transaction_group` comprueba que la suma algebraica de todos los movimientos del `transaction_group_id` por moneda sea exactamente igual a cero (`SUM(amount) = 0.000000000000000000`). En caso de discrepancia de siquiera 1e-18 unidades, la transacción completa hace `ROLLBACK` automático.\n","sha256_hash":"SHA256:AD9AC4C22A622885FE034B0234753EEBF183BD8A3F80B5E4AA711EBAD27CAC29","board_approval_act":"Acta de Directorio PSAV 2026 — Aprobación Manual Técnico M01 (Art. 11 RG CNV N° 1058/25)","effective_from":"2026-10-16T21:40:40.199933+00:00","is_active":true},{"id":"28da5a0a-8abb-459e-8691-b81d5f3255f7","corporate_id":"da700000-0000-4000-8000-000000000001","doc_type":"TNC_CUENTAS_DE_ORDEN_ART16_18_19","version_tag":"v1.0-DAVNEXT-CNV1058","title":"Términos y Condiciones de Uso y Régimen de Segregación en Cuentas de Orden (Arts. 16, 18 y 19 RG CNV 1058/25)","normative_reference":"RG CNV N° 1058/25","summary_markdown":"### 1. Identificación del Proveedor de Servicios de Activos Virtuales (PSAV)\\nEl presente contrato regula la relación entre el Cliente y **DAV NEXT S.A.** (CUIT N° **30-71960008-1**), con domicilio legal en **Av. Córdoba 315, Piso 1°, CABA**, operando en las Categorías 1°, 2°, 3°, 4° y 5° del Art. 4° bis de la Ley N° 25.246 y RG CNV N° 1058/25.\\n\\n### 2. Naturaleza Jurídica del Depósito y Cuentas de Orden (Arts. 16 y 18)\\nLos Activos Virtuales y fondos fiduciarios entregados por el Cliente permanecen en todo momento en propiedad exclusiva del Cliente y se contabilizan en **Cuentas de Orden (`MEMORANDUM_CLIENT`)**, separadas del patrimonio propio de **DAV NEXT S.A. (`PATRIMONIAL_OWN`)**.\\n\\n### 3. Prohibición de Uso Propio (Art. 19)\\n**DAV NEXT S.A.** tiene expresamente prohibido utilizar, prestar, gravar o disponer de los Activos Virtuales de los Clientes por cuenta propia o para el giro de sus negocios.","sha256_hash":"ad04c64c4a93d9c6231de2613b59935ec3a87fe6e048b65ecb915b5b7e996ed4","board_approval_act":"Acta de Directorio DAV NEXT S.A. N° 01/2026","effective_from":"2026-10-13T22:29:26.837087+00:00","is_active":true}]}