JP Morgan पर email रिकॉर्ड हटाने के लिए SEC ने जुर्माना लगाया

 (theregister.com)
1 पॉइंट द्वारा GN⁺ 2023-06-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • JP Morgan को Chase Bank से जुड़े 2018 के इलेक्ट्रॉनिक communication रिकॉर्ड बड़े पैमाने पर खोने के कारण लगभग 40 लाख डॉलर ($4m) का जुर्माना लगाया गया
  • हटाए गए रिकॉर्ड 1 जनवरी 2018 से 23 अप्रैल 2018 तक करीब 8,700 इलेक्ट्रॉनिक mailbox के लगभग 4.7 करोड़ इलेक्ट्रॉनिक communication थे, जिनमें से कुछ ऐसे business records थे जिन्हें कानूनन सुरक्षित रखना जरूरी था
  • कंपनी ने यह मानकर deletion job चलाई कि archive vendor की 36 महीने की retention setting सही ढंग से काम कर रही है, लेकिन पता चला कि Chase domain पर protection लागू नहीं थी
  • कम से कम 12 civil securities-संबंधी regulatory investigations में JP Morgan को subpoenas और document requests मिले, लेकिन permanently delete हुए रिकॉर्ड recover या submit नहीं किए जा सके
  • घटना के बाद कंपनी ने अपना retention coding और approval process लागू किया, और SEC ने भविष्य में उल्लंघन रोकने का आदेश तथा 40 लाख डॉलर की penalty भरने का आदेश दिया

4.7 करोड़ रिकॉर्ड हटना और SEC की कार्रवाई

  • JP Morgan को Chase Bank subsidiary से जुड़े 2018 के करोड़ों email रिकॉर्ड delete करने पर SEC ने 40 लाख डॉलर का जुर्माना लगाया
  • deletion का पैमाना लगभग 4.7 करोड़ electronic communication records था, जो करीब 8,700 electronic mailbox से जुड़े थे
    • target period 1 जनवरी 2018 से 23 अप्रैल 2018 तक था
    • इनमें से कई को 1934 के Securities Exchange Act के तहत सुरक्षित रखे जाने वाले business records माना गया
  • कम से कम 12 civil securities-संबंधी regulatory investigations में यह समस्या जारी रही
    • इनमें से 8 investigations SEC staff ने की थीं
    • JP Morgan को subpoenas और document requests मिले, लेकिन रिकॉर्ड permanently delete हो चुके थे, इसलिए उन्हें recover या submit नहीं किया जा सका

deletion project में हुई गलत धारणा

  • इसकी शुरुआत ऐसे project से हुई जिसका उद्देश्य सिस्टम से पुराने communications और documents हटाना था, जिन पर अब retention obligation नहीं था
  • JP Morgan द्वारा implement की गई process deletion के लिए पहचाने गए documents को सही ढंग से delete नहीं कर पा रही थी, और issue fix करने के दौरान 2018 की पहली तिमाही के electronic communications पर deletion job चलाई गई
    • उस समय JP Morgan का मानना था कि Exchange Act द्वारा आवश्यक 36 महीने की regulatory retention period के भीतर आने वाले records इस तरह store किए गए हैं कि उन्हें permanently delete नहीं किया जा सकता

archive vendor और 36 महीने की retention setting

  • JP Morgan ने communications storage संभालने वाले अनाम archiving vendor को जिम्मेदार माना
  • उस vendor ने JP Morgan और FINRA को कई बार आश्वासन दिया था कि उसका media storage 36 महीने की retention period से जुड़े Exchange Act rules का पालन करता है
    • JP Morgan ने माना कि इस अवधि के भीतर आने वाले documents deletion से protected हैं
  • मुकदमों जैसे अन्य उद्देश्यों के लिए बनाए रखने जरूरी documents की protection हेतु legal holds वाले mailboxes पर additional coding भी लागू की गई थी

असल deletion कैसे हुआ और कैसे पता चला

  • जून 2019 में Corporate Compliance Technology team email और instant messages सहित उन electronic communications को delete करने के project पर काम कर रही थी जिन्हें अब retain करने की जरूरत नहीं थी
  • JP Morgan और vendor द्वारा बनाई गई procedure सही documents delete नहीं कर पाई, तो team ने कई time periods पर deletion jobs चलाईं
    • इसमें 1 जनवरी 2018 से 23 अप्रैल 2018 तक के emails भी शामिल थे
    • team का मानना था कि retention के दायरे में आने वाले records को delete होने से रोकने के safeguards मौजूद हैं
  • असल में vendor ने JP Morgan के अंदरूनी Chase domain पर retention settings सही ढंग से apply नहीं की थीं
    • परिणामस्वरूप, legal holds की additional coding से protected items को छोड़कर उस domain के emails permanently delete हो गए
  • JP Morgan को अक्टूबर 2019 में यह बात पता चली, जब legal discovery team ने 2018 की शुरुआती अवधि के electronic communications missing पाए
  • कंपनी ने जनवरी 2020 में SEC को घटना की जानकारी दी

दोबारा न हो, इसके लिए कदम और SEC का निष्कर्ष

  • घटना के जवाब में JP Morgan ने अपना 36 महीने का retention coding implement किया और operating procedures को revamp किया
  • नई procedure इस बात को रोकती है कि जिन electronic communications पर retention obligation अभी बाकी है, उन पर deletion job न चलाई जाए
    • deletion job चलाने वाले कर्मचारी को senior information officer की approval लेनी होगी
  • SEC ने निष्कर्ष निकाला कि JP Morgan ने Exchange Act Section 17(a) और Rule 17a-4(b)(4) का जानबूझकर उल्लंघन किया
    • ये rules broker-dealer को business-related incoming communications और outgoing communications की copies कम से कम 3 साल तक सुरक्षित रखने की मांग करते हैं
  • SEC ने JP Morgan को भविष्य में उल्लंघन रोकने का आदेश और 40 लाख डॉलर penalty भरने का आदेश दिया
  • JP Morgan ने कहा कि वह recordkeeping obligations को गंभीरता से लेता है और processes व procedures को मजबूत करने के लिए कदम उठाए हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-06-27
Hacker News की राय

  • मोटे तौर पर स्थिति कुछ ऐसी लगती है: 1) जिस डेटा को कानूनी कारणों से सुरक्षित रखना ज़रूरी है, उसे सामान्य deletion प्रक्रिया से नहीं मिटना चाहिए 2) जिस डेटा को delete होना चाहिए, वह सही से delete नहीं हुआ 3) इसे ठीक करने के लिए 2018 में उस समय तक के deletion requests को मैन्युअली चलाया गया, और माना गया कि preservation वाला डेटा 1) के कारण सुरक्षित रहेगा 4) लेकिन किसी ने Chase domain पर भेजे गए email के लिए 1) वाली setting छोड़ दी। उस समय merger को हुए पहले ही 18 साल हो चुके थे 5) और 1.5 साल तक किसी को पता ही नहीं चला
    सबसे बड़ी समस्या 5) लगती है। गलती हो सकती है, लेकिन अगर समय रहते पता चल जाता तो backup में messages बचे होने की संभावना थी। अगर backup में भी नहीं थे, तो वह उससे भी बड़ी समस्या है। हालांकि legal discovery की वजह से शायद backup भी लंबे समय तक नहीं रखा गया होगा, उसी कारण से जिस कारण पुराने email शुरू से delete किए जा रहे थे

    • data handling से जुड़े कानूनों का enforcement लगभग नहीं के बराबर है, इसलिए वे मानो असल कानून की तरह काम ही नहीं करते। इसी वजह से ज़्यादातर कंपनियाँ data को काफ़ी लापरवाही से संभालती हैं
      अगर कोई ठोस वजह न हो, तो किसी कंपनी के लिए IT infrastructure पर ज़्यादा निवेश करना शायद तर्कसंगत नहीं लगता। बड़े पैमाने पर customer data leak भी practically दंडित नहीं होते, तो पिछले quarter की growth कम रहने से पहले से नाराज़ shareholders वाले board के सामने mitigation cost को कैसे justify किया जाए
    • लगता है कंपनियाँ वास्तव में ऐसे records को preserve करने के बजाय inbox और sent mailbox data तक access बनाए रखती हैं और उसे ही काफ़ी मान लेती हैं। कई environments में sent mailbox से email delete करने पर उसे लगभग recover करना असंभव हो सकता है
      जानना दिलचस्प होगा कि IT admins ने असल में क्या देखा है। क्या वे सच में हर message का log record रखते हैं, या किसी खास समय पर सभी accounts का snapshot जैसा कुछ रखते हैं
    • इसका दूसरे मुकदमों पर कितना असर पड़ा होगा?

  • मैं वकील नहीं हूँ, लेकिन कई देशों में judge adverse inference लागू कर सकता है और यह मान सकता है कि उस सबूत में क्या रहा होगा
    यह delete करने वाली party के पक्ष में नहीं जाएगा
    https://en.m.wikipedia.org/wiki/Adverse_inference

    • SEC न्याय दिलाने वाली संस्था कम और बैंकों की कठपुतली ज़्यादा लगती है। जिस कंपनी का quarterly net profit 12.62 billion dollar हो, उसके लिए 4 million dollar का fine कुछ भी नहीं है
    • अभी भी ऐसा हो सकता है। यह तो सिर्फ SEC का fine है, कानूनी नतीजे बाद में आ सकते हैं
      उन emails में से काफ़ी सारे शायद litigation hold के दायरे में रहे होंगे। अगर उस मुकदमे में Chase को जिन emails को preserve करना चाहिए था लेकिन वह नहीं कर पाया, उन पर निर्भर होना पड़े, तो judge jury को spoliation inference का निर्देश दे सकता है। यानी jury यह मान सकती है कि वह सबूत Chase के खिलाफ़ जाता
      हालांकि अगर यह दुर्भावना नहीं बल्कि अयोग्यता के कारण हुआ हो, तो संभावना कम हो जाती है
    • अगर असली सबूत judge की कल्पना से भी बदतर बातें दिखाता हो, तो उसका मतलब हुआ कि उन्हें “गलती से” delete कर देना बेहतर है
      मेरे हिसाब से ऐसे काफ़ी मामले हुए हैं
    • सिर्फ article देखकर यह भी हो सकता है कि JP Morgan खुद defendant या investigation target न हो। तब शायद adverse inference लागू न हो

  • मैंने खुद इस तरह की गड़बड़ी की है। नौकरी जॉइन किए 6 महीने भी नहीं हुए थे कि किसी ने खुद बनाई हुई keycard से building में unauthorized entry कर ली, और इस पर बड़ा internal investigation हुआ
    मुझसे कहा गया कि क्या हुआ यह देखने के लिए एक machine के event logs analyze करूँ, और करीब 12 लोगों वाली Teams meeting में event log पर right-click करते हुए मैंने गलती से delete दबा दिया, फिर लगभग reflex में confirmation dialog भी approve कर दिया
    काफ़ी शर्मिंदगी हुई, लेकिन मैंने तुरंत ईमानदारी से बता दिया। उसके बाद से मैं हमेशा पहले power plug निकालता हूँ और disk image लेता हूँ

    • जिज्ञासा से पूछ रहा हूँ, keycard बनाने वाला भी क्या आप ही थे?
    • अगर उसी क्षण machine की power तुरंत काट दी जाती, तो event logs लगभग निश्चित रूप से recover किए जा सकते थे। इसमें कुछ दिन लगते, लेकिन संदिग्ध malicious actor के सबूत न मिलने से तो बेहतर ही होता

  • finance sector में काम कर चुका हूँ, इसलिए यह सब बकवास लगता है
    infrastructure change तो छोड़िए, data manipulation करने के लिए भी अंतहीन signatures और meetings चाहिए होते हैं। किसी ex-employee का एक cloud folder संभालने के लिए भी करीब 13 meetings हो जाती हैं
    लेकिन जैसे ही मामला court तक पहुँचता है, अजीब तरह से बहुत सी चीज़ें अपने-आप, कंपनी के फ़ायदे में होने लगती हैं

    • finance sector के IT support में काम कर चुका हूँ, इसलिए “यह कई साल से टूटा हुआ था और किसी को पता नहीं चला” वाली बात ज़्यादा सही लगती है। मैंने ढेरों signatures और meetings देखी हैं, लेकिन अगर कोई implementation गलत कर दे और चीज़ें इतनी न टूटें कि लोग शिकायत करें, तो ऐसी प्रक्रियाएँ बेकार हो जाती हैं
    • backups भी होते हैं
      यह enterprise version है: IT department ने मेरा homework खा लिया। यह बेहूदा बहाना है, और “सज़ा” के नाम पर मामूली fine मिलता है
    • meetings सच में लाख बार होती हैं, लेकिन आख़िर में change लागू एक IT कर्मचारी ही करता है
      “ओह, मुझसे गलती हो गई” जैसी base failure rate को खत्म करने की cost exponential होती जाती है, और हर किसी के पास IT पर NASA-स्तर का budget नहीं होता
    • JP Morgan जैसे व्यवहार करने वाले finance players सचमुच अर्थव्यवस्था का cancerous tumor बन चुके हैं। वे अत्यधिक vascularization खींचते हैं, फिर दावा करते हैं कि अगर इन्हें काटा गया तो शरीर मर जाएगा, और अंततः पूरे शरीर को बर्बाद कर देते हैं
      हम इंसानी cancer का इलाज अभी तक इसलिए नहीं कर पाए कि हमने अपने बनाए हुए cancer पर आँखें मूँद रखी हैं

  • 4 million dollar fine? यह तो retention cost से कहीं सस्ता होगा

    • irony होगी अगर deleted messages में कुछ ऐसा लिखा हो: “क्या 4 million dollar, हमारी दूसरी करतूतों पर लगने वाले fine से सस्ता है?”
    • यह उस fine से भी सस्ता हो सकता है जो सबूत preserve रखने पर लगता
    • हमेशा की तरह यह बस | business | करने की cost है
    • काफ़ी संभव है कि सच में यही हो

  • अगर यह इतना उदास न होता, तो यहाँ दिख रही corruption की बेशर्मी और खुलापन बहुत हँसाने वाला होता। दुनिया में कौन ऐसी बकवास कहानी पर यक़ीन करेगा
    ऐसी घटनाओं पर fine B से शुरू होकर illions पर खत्म होने वाली रकम, यानी billions से शुरू होना चाहिए। फिर देखते हैं ऐसी “गलतियाँ” कितनी बार होती हैं

    • archive setting या configuration गलत होना काफ़ी plausible है, और वास्तव में इसकी संभावना भी अधिक लगती है। finance sector में काम करता हूँ, और system misconfiguration असामान्य नहीं है। archive settings की testing और review भी आमतौर पर बहुत thorough नहीं होती
      उदाहरण के लिए, मैंने एक ऐसे system पर काम किया है जो trillions के AUM वाले fund स्तर की holdings और trade information संभालता था। उसमें schema owner privileges के साथ SQL injection vulnerability थी। अच्छा हुआ कि वह internal app था, लेकिन कोई trading desk developer नाम टकराव वाली drop table statement गलती से paste कर सकता था
      जब मैंने यह सब person in charge को बताया, तो जवाब मिला, “real-time backup है, इसलिए बड़ी समस्या नहीं है।” मैंने पूछा, क्या आपने backup test किया है? जवाब था नहीं। backup से restore करने की procedure है? नहीं। 5 मिनट के outage पर हड़कंप मचाने वाले संगठन में restore में कितना समय लगेगा? पता नहीं
      अज्ञानता सचमुच एक विश्वसनीय व्याख्या है। regulated industries में भी यही हाल है
    • fine क्यों?
      ऐसी घटना की सज़ा banking license का स्थायी रद्दीकरण होनी चाहिए। जिस कंपनी में सबूत “गलती से” delete हो सकते हों, उस पर भरोसा कैसे किया जाए
    • करीब 3 लाख कर्मचारियों वाली JP Morgan में, क्या आपको सच में लगता है कि इस तरह की चीज़ जानबूझकर करने वाला कोई administrative-level corrupt secret network होगा और कोई whistleblower सामने नहीं आएगा?
      यह ज़्यादा plausible लगता है: https://www.sec.gov/news/press-release/2021-262
    • fine लगाने की ज़रूरत ही नहीं, अगर मुकदमे में ऐसे materials की ज़रूरत हो और data delete हुआ हो सकता है, तो हर ऐसे मामले में दूसरी party को default रूप से adverse inference लेने दिया जाए
    • fine? मेरा मतलब imprisonment है

  • इससे नीदरलैंड सरकार का वह मामला याद आता है जिसमें नई सरकार के गठन से जुड़े confidential documents “गलती से” delete कर दिए गए थे। उस प्रक्रिया की जाँच चल रही है, और बातचीत के transcripts वाले documents कुछ politicians के ख़िलाफ़ सबूत बन सकते थे
    यह बात और उभरकर आती है जब देखें कि सरकारी संस्थाएँ आम तौर पर document preservation में बेहद ढीली होती हैं

  • हर किसी से गलती होती है, तो ठीक है। अगली बार बस सबूत मत मिटाना

    • इसी बीच सरकार ने शायद पिछले 12 साल के tax payment records गलती से delete कर दिए हैं
      आप समझ सकते हैं कि ऐसा हो सकता है। अब भुगतान कीजिए

  • “गलती से”। हाँ, ज़रूर

    • अगर archive practices खुद को ही नुक़सान पहुँचाने को और आसान बना दें, तो शायद बोनस points भी मिलने चाहिए

  • 4 million dollar बहुत ही छोटी रकम लगती है। JP Morgan शायद दुनिया भर के पैमाने पर यह रकम एक घंटे से भी कम में कमा लेता होगा

    • 2022 में यह 177 billion dollar था, यानी लगभग 484 million dollar प्रतिदिन, और लगभग 20 million dollar प्रति घंटा
      यानी बस coffee break में कमाई जाने वाली रकम