JP Morgan ถูก SEC ปรับจากการลบประวัติอีเมล

 (theregister.com)
1 คะแนน โดย GN⁺ 2023-06-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • JP Morgan ถูกปรับ ประมาณ 4 ล้านดอลลาร์ ($4m) หลังสูญเสียบันทึกการสื่อสารอิเล็กทรอนิกส์จำนวนมากในปี 2018 ที่เกี่ยวข้องกับ Chase Bank
  • บันทึกที่ถูกลบคือการสื่อสารอิเล็กทรอนิกส์ประมาณ 47 ล้านรายการ จาก กล่องจดหมายอิเล็กทรอนิกส์ประมาณ 8,700 กล่อง ระหว่างวันที่ 1 มกราคมถึง 23 เมษายน 2018 โดยบางส่วนเป็นบันทึกทางธุรกิจที่กฎหมายกำหนดให้ต้องเก็บรักษา
  • บริษัทดำเนินการลบโดยเชื่อว่าการตั้งค่า การเก็บรักษา 36 เดือน ของผู้ให้บริการจัดเก็บทำงานถูกต้อง แต่ภายหลังพบว่าการป้องกันไม่ได้ถูกนำไปใช้กับโดเมนของ Chase
  • ในการสอบสวนด้านกฎระเบียบที่เกี่ยวข้องกับหลักทรัพย์ทางแพ่งอย่างน้อย 12 คดี JP Morgan ได้รับหมายเรียกและคำขอเอกสาร แต่ไม่สามารถกู้คืนหรือส่งมอบบันทึกที่ถูกลบถาวรได้
  • หลังเหตุการณ์ บริษัทได้นำระบบโค้ดสำหรับการเก็บรักษาและขั้นตอนอนุมัติของตนเองมาใช้ และ SEC สั่งให้ยุติการกระทำผิดในอนาคต พร้อมชำระ ค่าปรับ 4 ล้านดอลลาร์

การลบบันทึก 47 ล้านรายการและมาตรการลงโทษของ SEC

  • JP Morgan ถูก SEC ปรับ 4 ล้านดอลลาร์ จากการลบบันทึกอีเมลในปี 2018 หลายล้านรายการที่เกี่ยวข้องกับบริษัทลูก Chase Bank
  • ขนาดการลบอยู่ที่บันทึกการสื่อสารอิเล็กทรอนิกส์ประมาณ 47 ล้านรายการ จากกล่องจดหมายอิเล็กทรอนิกส์ประมาณ 8,700 กล่อง
    • ช่วงเวลาที่เกี่ยวข้องคือระหว่างวันที่ 1 มกราคมถึง 23 เมษายน 2018
    • หลายรายการในนั้นถูกพิจารณาว่าเป็นบันทึกทางธุรกิจที่ต้องเก็บรักษาตาม Securities Exchange Act of 1934
  • ปัญหานี้ส่งผลต่อการสอบสวนด้านกฎระเบียบที่เกี่ยวข้องกับหลักทรัพย์ทางแพ่งอย่างน้อย 12 คดี
    • ในจำนวนนี้ 8 คดีเป็นการสอบสวนที่ดำเนินการโดยเจ้าหน้าที่ SEC
    • JP Morgan ได้รับหมายเรียกและคำขอเอกสาร แต่เนื่องจากบันทึกถูกลบถาวร จึงไม่สามารถกู้คืนหรือส่งมอบได้

การตัดสินใจผิดพลาดในโครงการลบข้อมูล

  • จุดเริ่มต้นมาจากโครงการที่พยายามลบการสื่อสารและเอกสารเก่าที่ไม่มีภาระผูกพันต้องเก็บรักษาอีกต่อไปออกจากระบบ
  • กระบวนการที่ JP Morgan นำมาใช้ไม่สามารถลบเอกสารที่ระบุว่าเป็นเป้าหมายการลบได้อย่างถูกต้อง และระหว่างการแก้ปัญหา ได้มีการดำเนินงานลบกับการสื่อสารอิเล็กทรอนิกส์ในไตรมาสแรกของปี 2018
    • ขณะนั้น JP Morgan เชื่อว่าบันทึกที่อยู่ภายใน ระยะเวลาเก็บรักษาตามกฎระเบียบ 36 เดือน ที่ Exchange Act กำหนด ถูกจัดเก็บไว้ในลักษณะที่ไม่สามารถลบถาวรได้

ผู้ให้บริการจัดเก็บและการตั้งค่าเก็บรักษา 36 เดือน

  • JP Morgan เห็นว่าความรับผิดชอบอยู่ที่ ผู้ให้บริการอาร์ไคฟ์ นิรนามที่บริษัทว่าจ้างให้จัดเก็บการสื่อสาร
  • ผู้ให้บริการรายดังกล่าวเคยรับรองต่อ JP Morgan และ FINRA หลายครั้งว่า media storage ของตนปฏิบัติตามกฎของ Exchange Act เกี่ยวกับระยะเวลาเก็บรักษา 36 เดือน
    • JP Morgan จึงเห็นว่าเอกสารภายในช่วงเวลานี้ได้รับการป้องกันจากการถูกลบ
  • ยังมีการใช้โค้ดเพิ่มเติมกับกล่องจดหมายที่อยู่ภายใต้ legal holds เพื่อปกป้องเอกสารที่ต้องเก็บไว้ด้วยเหตุผลอื่น เช่น คดีความ

ลำดับเหตุการณ์การลบจริงและการค้นพบ

  • ในเดือนมิถุนายน 2019 ทีม Corporate Compliance Technology กำลังดำเนินโครงการลบการสื่อสารอิเล็กทรอนิกส์ที่ไม่จำเป็นต้องเก็บรักษาอีกต่อไป รวมถึงอีเมลและข้อความโต้ตอบแบบทันที
  • เมื่อขั้นตอนที่ JP Morgan และผู้ให้บริการสร้างขึ้นไม่สามารถลบเอกสารที่เหมาะสมได้ ทีมจึงดำเนินงานลบในหลายช่วงเวลา
    • ซึ่งรวมถึงอีเมลตั้งแต่วันที่ 1 มกราคมถึง 23 เมษายน 2018 ด้วย
    • ทีมเชื่อว่ามีมาตรการป้องกันที่ขัดขวางการลบบันทึกที่ต้องเก็บรักษา
  • แต่ในความเป็นจริง ผู้ให้บริการไม่ได้ใช้การตั้งค่าเก็บรักษากับ โดเมน Chase ภายใน JP Morgan อย่างถูกต้อง
    • ส่งผลให้อีเมลในโดเมนดังกล่าวถูกลบถาวร ยกเว้นรายการที่ได้รับการป้องกันด้วยโค้ดเพิ่มเติมของ legal holds
  • JP Morgan ทราบเรื่องนี้ในเดือนตุลาคม 2019 เมื่อทีม legal discovery พบว่าการสื่อสารอิเล็กทรอนิกส์ในช่วงต้นปี 2018 หายไป
  • บริษัทได้รายงานเหตุการณ์ต่อ SEC ในเดือนมกราคม 2020

มาตรการป้องกันการเกิดซ้ำและการวินิจฉัยของ SEC

  • JP Morgan ตอบสนองต่อเหตุการณ์ด้วยการนำ โค้ดเก็บรักษา 36 เดือน ของตนเองมาใช้ และปรับปรุงขั้นตอนการปฏิบัติงาน
  • ขั้นตอนใหม่ป้องกันไม่ให้มีการดำเนินงานลบกับการสื่อสารอิเล็กทรอนิกส์ที่ยังมีภาระผูกพันต้องเก็บรักษา
    • พนักงานที่ต้องการดำเนินงานลบต้องได้รับอนุมัติจากเจ้าหน้าที่สารสนเทศระดับสูง
  • SEC วินิจฉัยว่า JP Morgan จงใจละเมิด Exchange Act Section 17(a) และ Rule 17a-4(b)(4)
    • ข้อกำหนดดังกล่าวกำหนดให้ broker-dealer ต้องเก็บรักษาการสื่อสารขาเข้าที่เกี่ยวข้องกับธุรกิจและสำเนาการสื่อสารขาออกไว้อย่างน้อย 3 ปี
  • SEC สั่งให้ JP Morgan ยุติการกระทำผิดในอนาคตและชำระ ค่าปรับ 4 ล้านดอลลาร์
  • JP Morgan ระบุว่าบริษัทให้ความสำคัญกับภาระหน้าที่ในการเก็บรักษาบันทึกอย่างจริงจัง และได้ดำเนินมาตรการเพื่อเสริมความแข็งแกร่งให้กระบวนการและขั้นตอนต่างๆ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-06-27
ความคิดเห็นจาก Hacker News

  • ผมมองว่าสถานการณ์คร่าว ๆ เป็นแบบนี้: 1) ข้อมูลที่ต้องเก็บรักษาไว้ด้วยเหตุผลทางกฎหมายไม่ควรถูกลบด้วยกระบวนการลบปกติ 2) ข้อมูลที่ควรถูกลบกลับไม่ได้ถูกลบอย่างถูกต้อง 3) เพื่อแก้ปัญหานี้ จึงมีการรันคำขอลบทั้งหมดจนถึงเวลาปัจจุบันแบบแมนนวลในปี 2018 โดยเชื่อว่าข้อมูลที่ต้องเก็บรักษาจะถูกข้อ 1 ปกป้องไว้ 4) แต่มีคนลืมตั้งค่าข้อ 1 สำหรับอีเมลที่ส่งไปยังโดเมน Chase ตอนนั้นการควบรวมก็ผ่านไปแล้ว 18 ปี 5) ไม่มีใครสังเกตเห็นอยู่ 1.5 ปี
    ปัญหาใหญ่สุดน่าจะเป็นข้อ 5 ความผิดพลาดเกิดขึ้นได้ แต่ถ้ารู้ทันเวลา ก็น่าจะยังมีข้อความเหลืออยู่ในแบ็กอัป ถ้าไม่มีในแบ็กอัปด้วย นั่นเป็นปัญหาที่ใหญ่กว่ามาก อย่างไรก็ตาม ก็เป็นไปได้ว่าเพราะเรื่องการเปิดเผยพยานหลักฐานทางกฎหมาย แบ็กอัปจึงไม่ได้ถูกเก็บไว้นานอยู่แล้ว ด้วยเหตุผลเดียวกับที่ต้องลบอีเมลเก่าแต่แรก

    • กฎหมายเกี่ยวกับการจัดการข้อมูลแทบไม่ค่อยถูกบังคับใช้ เลยดูเหมือนว่า มันไม่ได้ทำงานเหมือนกฎหมายจริง ๆ ดังนั้นบริษัทส่วนใหญ่จึงจัดการข้อมูลอย่างค่อนข้างสะเพร่า
      ถ้าไม่มีเหตุผลที่หนักแน่น การให้บริษัทลงทุนกับโครงสร้างพื้นฐาน IT มากขึ้นอาจเป็นเรื่องไม่สมเหตุสมผลด้วยซ้ำ แม้แต่เหตุข้อมูลลูกค้ารั่วไหลครั้งใหญ่ก็แทบไม่ได้รับโทษ แล้วจะอธิบายต้นทุนการลดความเสี่ยงกับบอร์ดที่โกรธอยู่แล้วเพราะการเติบโตไตรมาสก่อนต่ำได้อย่างไร
    • ดูเหมือนว่าบริษัทต่าง ๆ ไม่ได้เก็บบันทึกเหล่านี้ไว้จริง ๆ แต่แค่รักษาสถานะให้ยังเข้าถึงข้อมูลในกล่องขาเข้าและกล่องขาออกได้ แล้วก็ถือว่าเพียงพอ ในหลายสภาพแวดล้อม ถ้าลบอีเมลจากกล่องขาออกแล้วก็แทบจะกู้คืนไม่ได้
      ผมอยากรู้ว่าคนทำ IT เคยเห็นกรณีจริงเป็นอย่างไร เขาเก็บ บันทึกล็อก ของทุกข้อความจริงไหม หรือมีแค่สแนปช็อตของทุกบัญชีในบางช่วงเวลา
    • เรื่องนี้ส่งผลต่อคดีอื่นมากแค่ไหน?

  • ผมไม่ใช่ทนาย แต่ในหลายประเทศ ผู้พิพากษาสามารถใช้ ข้อสันนิษฐานในทางเสียหาย (adverse inference) เพื่อสันนิษฐานได้โดยพฤตินัยว่ามีอะไรอยู่ในหลักฐานนั้น
    มันคงไม่เป็นผลดีต่อฝ่ายที่ลบทิ้ง
    https://en.m.wikipedia.org/wiki/Adverse_inference

    • ผมมองว่า SEC ไม่ใช่หน่วยงานที่ทำให้เกิดความยุติธรรม แต่แทบเป็นหุ่นเชิดของธนาคารมากกว่า ค่าปรับ 4 ล้านดอลลาร์กับบริษัทที่มีกำไรสุทธิรายไตรมาส 12.62 พันล้านดอลลาร์ นั้นแทบไม่มีความหมาย
    • ผมว่ายังมีโอกาสเป็นแบบนั้นได้ นี่เป็นแค่ค่าปรับจาก SEC ส่วนผลทางกฎหมายอาจตามมาทีหลัง
      อีเมลจำนวนมากน่าจะอยู่ภายใต้คำสั่งเก็บรักษาหลักฐานในคดีความ ถ้า Chase ต้องพึ่งอีเมลที่ควรเก็บไว้แต่เก็บไม่สำเร็จในคดีเหล่านั้น ผู้พิพากษาอาจสั่งคณะลูกขุนด้วย ข้อสันนิษฐานการทำลายหลักฐาน (spoliation inference) กล่าวคือ คณะลูกขุนสามารถอนุมานได้ว่าหลักฐานนั้นน่าจะเป็นผลเสียต่อ Chase
      แต่ถ้าเป็นเพราะความไร้ความสามารถมากกว่าความจงใจ โอกาสก็จะน้อยลง
    • ถ้าหลักฐานจริงแสดงสิ่งที่เลวร้ายกว่าสิ่งที่ผู้พิพากษาจะสันนิษฐาน ก็แปลว่าการลบแบบ “เผลอ” จะดีกว่า
      ผมคิดว่ามีกรณีแบบนี้เกิดขึ้นไม่น้อย
    • จากที่อ่านในบทความ อาจเป็นไปได้ว่า JP Morgan ไม่ได้เป็นจำเลยหรือเป้าหมายการสอบสวน ถ้าเป็นแบบนั้น ข้อสันนิษฐานในทางเสียหาย อาจใช้ไม่ได้

  • ผมเคยเป็นคนก่อเหตุแบบนี้ด้วยตัวเอง ตอนทำงานยังไม่ถึง 6 เดือน มีการสอบสวนภายในครั้งใหญ่เพราะมีคนใช้คีย์การ์ดทำเองเพื่อเข้าอาคารโดยไม่ได้รับอนุญาต
    ผมถูกขอให้วิเคราะห์ event log ของเครื่องหนึ่งเพื่อดูว่าเกิดอะไรขึ้น แล้วระหว่างที่กำลังคลิกขวาที่ event log ในการประชุม Teams ที่มีคนอยู่ราว 12 คน ผมดันกดลบโดยไม่ตั้งใจ และเผลอกดยืนยันในกล่องโต้ตอบไปด้วยแบบอัตโนมัติ
    ค่อนข้างน่าอาย แต่ผมก็พูดความจริงทันที หลังจากนั้นผมจะถอดปลั๊กแล้วทำ disk image ก่อนเสมอ

    • อยากรู้เฉย ๆ ว่าคนทำคีย์การ์ดคนนั้นก็คือคุณเองหรือเปล่า?
    • ถ้าตอนนั้นคุณดึงปลั๊กเครื่องทันที ก็น่าจะกู้ event log กลับมาได้เกือบแน่นอน อาจใช้เวลาหลายวัน แต่ก็น่าจะดีกว่าไม่มีหลักฐานของผู้ต้องสงสัยว่ากระทำโดยเจตนาร้าย

  • จากประสบการณ์ที่เคยทำงานในวงการการเงิน ฟังดูเป็นเรื่องเหลวไหล
    แค่จะปรับเปลี่ยนโครงสร้างพื้นฐานยังต้องใช้ลายเซ็นและการประชุมไม่รู้จบ ไม่ต้องพูดถึงการไปยุ่งกับข้อมูล กว่าจะจัดการโฟลเดอร์คลาวด์ของพนักงานที่ลาออกคนเดียวได้ก็มีประชุมกันประมาณ 13 ครั้ง
    แต่พอถึงเวลาขึ้นศาล กลับมีเรื่องหลายอย่างเกิดขึ้นเองอย่างน่าประหลาดในทางที่เป็นประโยชน์ต่อบริษัท

    • จากประสบการณ์ที่เคยซัพพอร์ตแผนก IT ของสายการเงิน ผมว่าฝั่ง “มันพังมาหลายปีแล้วแต่ไม่มีใครรู้” ดูแม่นกว่า ผมเห็นลายเซ็นกับการประชุมมามากมาย แต่ถ้ามีใครทำพลาดตอนติดตั้งใช้งาน แล้วมันไม่ได้พังหนักจนคนต้องร้องเรียน ขั้นตอนพวกนั้นก็หมดความหมาย
    • ยังมีแบ็กอัปด้วย
      นี่คือเวอร์ชันองค์กรของคำว่า “ฝ่าย IT กินการบ้านผมครับ” เป็นข้ออ้างที่ไร้สาระ และก็ถูก “ลงโทษ” แค่ค่าปรับเล็กน้อย
    • จะประชุมกันเป็นล้านครั้งก็จริง แต่สุดท้ายคนที่ลงมือใช้การเปลี่ยนแปลงก็คือเจ้าหน้าที่ IT แค่คนเดียว
      ต้นทุนในการกำจัดอัตราการเกิดพื้นฐานของคำว่า “อุ๊ปส์ พลาดไป” นั้นเพิ่มขึ้นแบบทวีคูณ และไม่ใช่ทุกคนจะมีงบ IT ระดับ NASA
    • ผู้เล่นในภาคการเงินที่ทำตัวคล้าย JP Morgan ได้กลายเป็น เนื้องอกร้ายของระบบเศรษฐกิจ ไปแล้วอย่างแท้จริง พวกมันดึงทรัพยากรเกินควรเข้าหาตัวเอง แล้วโน้มน้าวว่าถ้าตัดออก ร่างกายจะตาย สุดท้ายกลับพาร่างกายทั้งหมดไปสู่ความพินาศ
      ที่เรายังรักษามะเร็งของมนุษย์ไม่ได้ ก็เพราะเราหลับตาให้กับมะเร็งที่เราสร้างขึ้นเอง

  • ค่าปรับ 4 ล้านดอลลาร์ เหรอ? ถูกกว่าค่าเก็บรักษาข้อมูลอีกมั้ง

    • ถ้าในข้อความที่ถูกลบมีอะไรทำนองว่า “4 ล้านดอลลาร์ถูกกว่าค่าปรับจากเรื่องอื่นที่เราทำไว้ไหม?” ก็คงประชดประชันดี
    • มีโอกาสว่าจะยังถูกกว่าค่าปรับที่เดิมควรจะโดน ถ้าเก็บหลักฐานเอาไว้
    • ก็แค่ต้นทุนในการทำ | ธุรกิจ | ตามปกติ
    • มีแนวโน้มสูงว่าเป็นแบบนั้นจริง

  • ถ้ามันไม่หดหู่เกินไป เรื่องนี้คงตลกมากกับความเปิดเผยและโจ่งแจ้งของความ腐败ที่เห็นอยู่ตรงหน้า ใครบนโลกจะเชื่อเรื่องเหลวไหลแบบนี้กัน
    ค่าปรับสำหรับเรื่องแบบนี้ควร ขึ้นต้นด้วย B แล้วลงท้ายด้วย illions กล่าวคือควรเริ่มที่ระดับ billions แล้วค่อยมาดูกันว่าความผิดพลาดแบบนี้ยังจะเกิดบ่อยแค่ไหน

    • เรื่องการตั้งค่าหรือคอนฟิก archive ผิดฟังดูค่อนข้างน่าเชื่อ และมีโอกาสเกิดขึ้นจริงสูง ผมทำงานในวงการการเงิน และระบบ ตั้งค่าผิด ไม่ใช่เรื่องหายาก การทดสอบและทบทวนการตั้งค่า archive ก็มักไม่ละเอียดนัก
      ตัวอย่างเช่น ผมเคยทำระบบที่จัดการข้อมูลการถือครองและการซื้อขายของกองทุนที่มีสินทรัพย์ภายใต้การบริหารระดับ trillions มีช่องโหว่ SQL injection ด้วยสิทธิ์เจ้าของ schema โชคดีที่เป็นแอปภายใน แต่ก็เป็นไปได้ที่นักพัฒนาฝั่ง trading desk จะเผลอวางคำสั่ง drop table ที่ชื่อชนกันเข้าไป
      พอผมรายงานทั้งหมดนี้ให้คนรับผิดชอบฟัง คำตอบที่ได้คือ “ไม่เป็นปัญหาใหญ่ เพราะเรามี real-time backup” พอถามว่าเคยทดสอบแบ็กอัปไหม ก็บอกว่าไม่เคย พอถามว่ามีขั้นตอนกู้คืนจากแบ็กอัปไหม ก็บอกว่าไม่มี พอถามว่าใช้เวลากู้คืนเท่าไรในองค์กรที่โกลาหลแม้แค่ล่ม 5 นาที ก็บอกว่าไม่รู้
      ความไม่รู้นี่แหละเป็นคำอธิบายที่น่าเชื่อถือมาก แม้ในอุตสาหกรรมที่ถูกกำกับดูแลก็เหมือนกัน
    • ทำไมต้องแค่ปรับ?
      บทลงโทษสำหรับเรื่องแบบนี้ควรเป็น การเพิกถอนใบอนุญาตประกอบกิจการธนาคารอย่างถาวร จะไว้ใจบริษัทที่ทำหลักฐาน “หายไปเพราะความผิดพลาด” ได้อย่างไร
    • คุณคิดจริง ๆ เหรอว่าที่ JP Morgan ซึ่งมีพนักงานราว 300,000 คน จะมีเครือข่ายลับคอร์รัปชันระดับผู้บริหารที่จงใจทำเรื่องนี้ และไม่มีผู้แจ้งเบาะแสเลยแม้แต่คนเดียว?
      ผมว่าคำอธิบายนี้น่าเชื่อกว่ามาก: https://www.sec.gov/news/press-release/2021-262
    • ไม่จำเป็นต้องปรับเลยด้วยซ้ำ ถ้าเอกสารพวกนี้จำเป็นต่อการฟ้องร้อง ก็แค่ให้คู่กรณีอีกฝ่ายได้ ข้อสันนิษฐานในทางเสียหาย เป็นค่าเริ่มต้นทุกครั้งที่มีโอกาสว่าข้อมูลถูกลบไป
    • ค่าปรับเหรอ? น่าจะต้องพูดถึงการจำคุกมากกว่า

  • ทำให้นึกถึงกรณีที่รัฐบาลเนเธอร์แลนด์ “เผลอ” ลบเอกสารลับที่เกี่ยวข้องกับการจัดตั้งรัฐบาลใหม่ ตอนนี้กระบวนการนั้นยังอยู่ระหว่างการสอบสวน และเอกสารที่มีบันทึกบทสนทนาก็อาจถูกใช้เป็นหลักฐานที่เป็นผลเสียต่อบรรดานักการเมืองบางคนได้
    ยิ่งเด่นชัดขึ้นไปอีกเมื่อคิดว่าหน่วยงานรัฐมักหละหลวมมากกับการเก็บรักษาเอกสาร

  • ทุกคนพลาดกันได้ ไม่เป็นไร ครั้งหน้าแค่อย่าลบหลักฐานก็พอ

    • ระหว่างนั้นดูเหมือนรัฐบาลจะเผลอลบประวัติการชำระภาษีของคุณตลอด 12 ปีที่ผ่านมาไปด้วย
      คุณคงเข้าใจได้แหละว่ามันเกิดขึ้นได้ ตอนนี้กรุณาจ่ายมาด้วย

  • “เผลอ” นะ แน่นอนสิ

    • ถ้าเป็นแนวทางการเก็บ archive ที่ช่วยให้ยิงตัวเองที่เท้าได้ง่ายขึ้น ก็ควรให้คะแนนเพิ่มด้วย

  • 4 ล้านดอลลาร์ฟังดูเป็นเงินเล็กน้อยมาก JP Morgan น่าจะหาเงินจำนวนนั้นได้ในเวลาไม่ถึงหนึ่งชั่วโมงทั่วโลก

    • ในปี 2022 อยู่ที่ 177 พันล้านดอลลาร์ เท่ากับราว 484 ล้านดอลลาร์ต่อวัน หรือประมาณ 20 ล้านดอลลาร์ต่อชั่วโมง
      ประมาณเงินที่หาได้ตอนพักดื่มกาแฟ