बैंक की तरह देखना

 (bitsaboutmoney.com)
2 पॉइंट द्वारा GN⁺ 2023-11-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • बैंक लेजर की तरह पैसों की आवाजाही ट्रैक करने में मजबूत होते हैं, लेकिन खाता बंद करना, fraud से निपटना, कार्ड दोबारा जारी करना, या संपत्ति जब्ती जैसे लंबे संदर्भ वाले मामलों में वे ग्राहक को “याददाश्तहीन संगठन” जैसे लग सकते हैं
  • समस्या के केंद्र में खंडित रिकॉर्ड सिस्टम है, जहां core banking system, ledger, ticket system, और विभाग-विशेष tools अलग-अलग चलते हैं
  • लागत कम रखने के लिए customer support को Tier One·Two·Three में बांटा जाता है; जैसे-जैसे अधिकार और पास किया जाने वाला संदर्भ सीमित होता है, ग्राहक को वही समस्या बार-बार समझानी पड़ती है
  • आधिकारिक support hierarchy को बायपास करने वाले escalation रास्ते भी होते हैं; पत्रकार, regulator, या वरिष्ठ विभाग तक पहुंचे मुद्दों को कहीं अधिक महंगी विशेषज्ञ टीमें संभाल सकती हैं
  • Suspicious Activity Report(SAR) जैसी गोपनीय बाध्यताएं खाते बंद करने का कारण समझाने से रोकती हैं; इसलिए खराब customer experience का एक हिस्सा सिर्फ तकनीकी कमी नहीं बल्कि regulatory choices का भी परिणाम है

बैंक “याद” क्यों नहीं रख पाते

  • बैंक पैसों की आवाजाही दर्ज करने वाले लेजर में तो मजबूत होते हैं, लेकिन ग्राहक से हुई बातचीत, पहले किए गए वादे, या कई महीनों/सालों तक फैले किसी मामले के संदर्भ जैसी दूसरी तरह की सच्चाइयों में कमजोर होते हैं
  • खाता बंद होना, Zelle या credit card fraud, debit card reissue, mortgage foreclosure जैसी अलग-अलग समस्याओं में भी ग्राहक अनुभव अक्सर एक जैसा दोहराया जाता है
    • हर बार शुरुआत से समझाना पड़ता है
    • पिछले प्रतिनिधि का किया वादा अगले प्रतिनिधि तक नहीं पहुंचता
    • बैंक के अंदर जवाबदेही धुंधली हो जाती है
  • ऐसे मामले बैंक की कुल गतिविधियों की तुलना में अपवाद हैं, लेकिन रोज होते हैं, और कुछ ग्राहकों के लिए बहुत बड़ा नुकसान पैदा कर सकते हैं

Core banking और record systems की सीमाएं

  • बैंक का केंद्रीय काम आमतौर पर core कहलाने वाली system में प्रोसेस होता है
    • बड़े बैंकों के पास जटिल in-house sub-systems हो सकते हैं
    • कई बैंक Jack Henry, Fiserv जैसे core processors की systems को license करते हैं
  • core बैंक के बहुत से काम संभालता है, लेकिन बैंक के अंदर की कई systems और ledgers से जुड़ा होने के कारण यह वास्तविकता को उतनी सटीकता से नहीं दर्शा पाता जितनी उम्मीद की जाती है
  • बैंक systems कई वर्षों के software development, regulatory changes, और competitive pressure की जमा हुई परतों के अधिक करीब हैं
  • हर बार जब जिम्मेदारी संगठन, computer system, या बैंक के अंदर के किसी group के बीच स्थानांतरित होती है, कुछ मामले टूट जाते हैं
    • बैंक के operational issues का बड़ा हिस्सा system boundaries पर पैदा होता है
    • security vulnerabilities भी तब पैदा हो सकती हैं जब system A और B अस्थायी रूप से एक ही वास्तविकता को अलग तरह से समझें

Ticket system भी पूरा समाधान नहीं है

  • ticket system कम से कम इतना अपरिवर्तनीय नियम लागू करता है कि case number वाला कोई issue Group A से Group B में गया है
    • यह देखा जा सकता है कि Group B 10,342 मामलों को संभाल रहा है
    • यह देखा जा सकता है कि Group B ने एक महीने से 76 मामलों पर कार्रवाई नहीं की
    • यह भी देखा जा सकता है कि किसी खास कर्मचारी का performance उसके साथियों से अलग है
  • लेकिन ticket system core नहीं है, और न ही यह वास्तविक customer account या payment का सीधा system of record है
  • ticket system को भी दूसरे sub-systems के साथ integrate करना पड़ता है, इसलिए उसके interfaces पर नई समस्याएं पैदा होती हैं
  • बैंक systems में जानबूझकर डिजाइन किए गए हिस्से और संयोग से जमा हुए हिस्से दोनों मिले-जुले होते हैं

M&A के बाद बची रहने वाली parallel systems

  • बैंकिंग उद्योग ने दशकों तक consolidation देखा है, और merged banks अपनी systems को तुरंत एक में नहीं समेट पाते
  • merger के बाद दोनों बैंकों की systems कई वर्षों तक parallel चलती हैं, और integration plan आमतौर पर इस दिशा में बढ़ता है कि एक system “winner” बने और दूसरी “loser”
  • business reasons से loser system के कुछ हिस्से अनिश्चितकाल तक बने रहते हैं, और पुराने systems तथा पिछली acquisitions के अवशेष winner system में जोड़ दिए जाते हैं
  • First Republic को acquire करने के बाद Chase के मामले में, दोनों तरफ की systems यह पहचानती हैं कि एक ही व्यक्ति के दोनों तरफ account हैं, लेकिन महत्वपूर्ण जानकारी अभी भी साझा नहीं कर पातीं
    • Chase, First Republic द्वारा इस्तेमाल न किए गए home loan conversion schedule की जानकारी देता है
    • First Republic ने वास्तव में जो Line of Credit दी थी, उसकी जानकारी नहीं होती
    • First Republic core द्वारा serviced account balance को Chase branch में देखने के लिए अतिरिक्त integration काम चाहिए

कर्मचारियों के internal screens भी वास्तविकता से मेल न खा सकते हैं

  • बैंक कई internal systems बनाते हैं जो core और ledger से जुड़े होते हैं, ताकि कर्मचारी customer accounts देख सकें और उन पर कार्रवाई कर सकें
  • ये employee-facing screens भी account की वास्तविक स्थिति से अलग हो सकती हैं
    • उदाहरण के लिए कुछ screens pending transaction नहीं दिखातीं
    • pending transaction ग्राहक के नजरिए से settled transaction जैसा असर डाल सकती है
  • ऐसी कमी इसलिए नहीं होती कि किसी ने जानबूझकर “pending transactions को बाहर रखें” तय किया हो, बल्कि यह पुराने requirements documents और code में बची साधारण गलती का लंबे समय तक बने रहना हो सकता है
  • operations team बैंक software की समस्याओं को engineering या procurement organization तक पहुंचाकर ठीक करवाए, ऐसी संरचना कल्पना से कम कंपनियों में होती है

परतदार customer support structure

  • लागत कम रखने के लिए बैंक customer support organization को काम और अधिकार के हिसाब से कड़े तौर पर बांटते हैं
  • किसी सामान्य financial institution की retail banking support आमतौर पर Tier One, Tier Two, Tier Three में बंटी होती है
  • Tier One सबसे सरल समस्याएं संभालता है या उन्हें Tier Two तक पहुंचाता है
    • इसके पास सीमित read-only interface और कुछ pre-defined buttons होते हैं
    • यह scripts और flowcharts के आधार पर ग्राहक की Tier Two तक पहुंच को gate करता है
  • Tier Two के पास अधिक अनुभव और सीमित compensation authority होती है
    • यह मनमाने कारणों से छोटी रकम ग्राहक के account में credit करके उसे operational loss के रूप में दर्ज कर सकता है
    • उदाहरण के लिए लगभग 200 dollar से कम compensation की कोई सीमा हो सकती है, जिसके लिए management chain या specialist की जरूरत न पड़े
  • Tier Three customer support या operations organization में होता है, और इसका काम साधारण script follow करने से अधिक जटिल case reconstruction और problem-solving के करीब होता है
    • यह कई systems से वे procedural histories इकट्ठा करता है जो ledger में दर्ज नहीं होतीं
    • यह अंतिम decision-maker नहीं होता, लेकिन दूसरे specialists के निर्णय के लिए पूरे मामले को व्यवस्थित करता है

ग्राहक को वही बात बार-बार दोहराने पर मजबूर करने वाली संरचना

  • Tier One से Tier Two में जाते समय पास किया गया संदर्भ बहुत छोटा हो सकता है
    • अच्छी तरह चलने वाली systems में भी सिर्फ एक tweet जितना summary पास हो सकता है
    • कई financial institutions उस स्तर तक भी नहीं पहुंचते
  • ग्राहक Tier Two या Tier Three तक पहुंचने पर भी वही समस्या शुरुआत से फिर समझाने को मजबूर हो सकता है
  • विभागों के बीच handoff में भी इसी तरह की समस्या दोहराई जाती है
    • उदाहरण के लिए बैंक को ग्राहक को cheque भेजना था, लेकिन वह डाक से नहीं पहुंचा; ऐसे में Tier Two के पास “reissue cheque” button न हो सकता है
    • Tier Two को operations team के लिए ticket बनाकर कहना पड़ता है कि “कोई फोन करेगा”
    • वास्तव में फोन गया या नहीं, इसे verify करने की system शायद न हो
  • ग्राहक को लग सकता है कि उससे झूठ बोला गया, लेकिन Tier Two agent ने सिर्फ script पढ़ी होती है, operations team हमेशा जलती हुई प्राथमिकताओं से जूझ रही होती है, और senior management के पास इस समस्या को अलग करके देखने के metrics नहीं होते

Branch staff भी सर्वशक्तिमान समाधानकर्ता नहीं हैं

  • पारंपरिक बैंक ग्राहक मानते हैं कि branch staff या branch manager उनकी समस्या हल कर देंगे, लेकिन bank branches की skill level घट गई है
  • कई branch कर्मचारी सिर्फ अपेक्षाकृत सरल समस्याएं हल कर सकते हैं, और जटिल मामलों के लिए उन्हें भी ग्राहक की तरह phone support tree से गुजरना पड़ता है
  • कुछ बैंकों में branch screen और Tier Two agents के बीच context share हो सकता है, लेकिन कुछ मामलों में कर्मचारी बैंक को यह तक साबित नहीं कर पाते कि वे खुद बैंक के कर्मचारी हैं
  • अमेरिकी financial institutions की technical maturity संस्थान-दर-संस्थान बहुत अलग होती है

आधिकारिक परतों को बायपास करने वाली escalation

  • लगभग हर financial institution में ऐसी escalation path होती है जो सामान्य support layers के अधिकांश या सभी हिस्से को पार करके decision-makers तक पहुंचती है
  • अगर कोई पत्रकार बैंक से ऐसी विधवा के मामले पर प्रतिक्रिया मांगे जो अनुचित foreclosure के कगार पर हो, या regulator किसी व्यक्ति की ओर से हस्तक्षेप करे, तो मामला समस्या-समाधान के लिए बनी टीम तक पहुंचने की संभावना बहुत अधिक होती है
  • सामान्य ग्राहक भी VP of Retail Banking, Office of the President, Investor Relations आदि को कागजी चिट्ठी भेजकर बैंक को इसी तरह सक्रिय कर सकते हैं
  • ये टीमें जटिल मामलों में कागजी notes बनाए रखती हैं, और कई दिनों तक याददाश्त व विवेक के साथ काम करने वाले specialists से बनी होती हैं
  • यह तरीका बहुत महंगा है, और problem-resolution team की प्रति-केस लागत tiered support system की तुलना में 100 गुना से भी अधिक हो सकती है

सबको specialist service क्यों नहीं दी जाती

  • ऐसा high-discretion specialist support जो कोई भी समस्या संभाल सके, बहुत महंगा होता है और समय के साथ और महंगा होता जाता है
  • अगर ग्राहक चाहते हैं कि बैंक की फोन line रात 2 बजे भी उठे और वह मुफ्त भी हो, तो बैंक tiered support system चुनेंगे
  • समाज भी tiered support system चाहता है
    • एक high school student भी checking account खोलकर debit card से Amazon पर खरीदारी कर सकता/सकती है
    • working-class इलाकों में भी bank branches चलाई जा सकती हैं
  • समझदार banking users के लिए यह आकलन करना उपयोगी है कि उनकी समस्या Tier Two में हल हो सकती है या उस तरह के मामले में आती है जिसके लिए छह-अंकीय वेतन पाने वाले specialist की जरूरत होगी
  • बायपास रास्ते संयोग नहीं बल्कि जानबूझकर डिजाइन किए गए होते हैं, और दुरुपयोग कम करने के लिए वे अक्सर ऐसे व्यवहार या financial-industry markers मांगते हैं जो professional-managerial class जैसे लगें

Suspicious Activity Report और ऐसे account closures जिनका कारण नहीं बताया जा सकता

  • अगर बैंक किसी account को बिना कारण बताए बंद कर दे और कोई भी समझा न सके, तो संभव है कि बैंक कानून का पालन कर रहा हो
  • ग्राहक के बारे में कई Suspicious Activity Report(SAR) दाखिल होने के बाद बैंक संबंध को “independent” और “commercial” decision बताकर समाप्त कर सकता है
  • SAR पूरी तरह निर्दोष कारणों से भी दाखिल हो सकती है, और यह जरूरी नहीं कि कोई गलत काम हुआ हो
  • SAR नियमों के तहत गोपनीय होती है
    • 12 CFR § 21.11(k)(1) बैंक, उसके directors, officers, employees, और agents को SAR या उसके अस्तित्व का खुलासा करने वाली जानकारी साझा करने से रोकता है
    • subpoena या disclosure request मिलने पर भी उन्हें इस प्रावधान और 31 U.S.C. 5318(g)(2)(A)(i) का हवाला देकर मना करना होता है
  • compliance organization अक्सर यह सुनिश्चित करती है कि SAR अलग sub-system में रहे, और सिर्फ वही लोग उसे देख सकें जो उसे लिखते हैं और FinCEN को भेजते हैं
  • अगर SAR sub-system account ownership को दूसरी systems से अलग तरह से देखता है, तो गलत तरीके से दाखिल SAR की जांच करना भी इस समस्या से टकरा सकता है कि ग्राहक को जांच के बारे में बताया नहीं जा सकता

क्या बदल सकता है

  • बैंक की “object permanence की कमी” न तो एक दिन में पैदा हुई है और न एक दिन में ठीक हो सकती है
  • समाधान का बड़ा हिस्सा technical improvement में है
    • पहले software में सक्षम financial institutions लगभग नहीं थे
    • अब अरबों-खरबों dollar खर्च करने के बाद कुछ गिने-चुने financial institutions ने यह क्षमता हासिल की है
  • tiered support model ग्राहकों को परेशान कर सकता है, लेकिन यह वही तकनीक भी है जिसने financial services की लागत घटाई और credit card व discount broker जैसी product innovation को संभव बनाया
  • सुधार कई रास्तों से आ सकता है
    • जारी बैंक consolidation
    • ऐसे external technology providers का उपयोग जो सही तथ्यों को अपने-आप रिकॉर्ड करें और उन पर कार्रवाई करें
    • operations का बैंक के भीतर अधिक प्रतिष्ठित क्षेत्र बनना और internal structure को बदलना
    • Cash App और Lincoln Savings Bank जैसी partnerships, जहां companies और banks technical customer experience को प्राथमिकता देते हैं
  • 12 CFR § 21.11(k)(1) जैसे नियमों के पीछे समाज के वांछित उद्देश्य हैं, लेकिन जब तक वे नियम मौजूद हैं, अमेरिका में ऐसे लोग बने रहेंगे जिनके accounts बंद होंगे और उन्हें कारण नहीं बताया जा सकेगा, और उनमें से कई ने शायद कुछ गलत किया भी नहीं होगा

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

1 टिप्पणियां

 
GN⁺ 2023-11-08
Hacker News की रायें

  • Patio11 संस्थागत दुनिया कैसे चलती है, और उसके bias को समझने के लिए मेरी जानकारी में सबसे अच्छा स्रोत है
    संस्थाओं को बार-बार इस तरह design किया जाता है कि कुछ व्यवहारों को reward मिले और कुछ को नहीं, और हमेशा reward पाने वाले व्यवहारों में से एक professional-managerial वर्ग की प्राथमिक access होती है
    यह लेख बैंक के अंदरूनी कामकाज के जरिए यह दिखाता है, और इससे भी ज़्यादा चुभने वाला लेख https://www.bitsaboutmoney.com/archive/the-waste-stream-of-c... है, जो दिखाता है कि गरीब लोगों की रक्षा करने वाले नियम असल में कैसे सिर्फ उन लोगों की मदद करते हैं जिनके पास professional-managerial कौशल तक access है
    काश लोगों को उनका नज़रिया संक्षेप में समझाने का कोई तरीका होता, लेकिन जिन systems में ऐसा होता है वे बेहद जटिल होते हैं, और वही जटिलता अपने-आप में वजह बन जाती है कि प्राथमिक access के लिए professional-managerial कौशल की जरूरत क्यों पड़ती है

    • दुनिया के सबसे बड़े बैंकों में से एक के Americas क्षेत्र का CTO रहने और consumer bank रखने के बाद हाल ही में उसे बेचने वाले व्यक्ति के तौर पर, Patio11 के पिछले लेखों में ऐसी बातें हैं जिन पर यहां बोलना मुश्किल है, लेकिन यह खास discussion मैंने कुछ लोगों के साथ share किया है
      हालांकि @patio11 ने इस साल जो कुछ interpretations दिए, उन्हें ज्यों-का-त्यों आगे बढ़ाना मुश्किल था। बैंक के अंदर कई स्तरों पर वे सुनने में plausible लगते हैं, लेकिन वास्तव में चीजें उसी वजह से काम करती हों ऐसा नहीं था; शायद यह इस बात का असर है कि वे organization के किस level या silo से संपर्क में हैं, या G-SIFI जैसे दूसरे तरह के बैंकों की तुलना में किसी खास प्रकार के बैंक से उनका संपर्क ज्यादा रहा है: https://www.fsb.org/work-of-the-fsb/market-and-institutional...
      फिर भी सुधार में रुचि रखने वाले industry executives को इसे जरूर पढ़ना चाहिए। इसमें वे हिस्से सामने आते हैं जहां @patio11 आम तौर से अलग lens से देखते हुए “perception ही reality है” वाली बात दिखाते हैं, और कारणों की attribution अलग हो तब भी उस perception को बदलने के लिए क्या ठीक करना होगा, यह निकाला जा सकता है
    • @patio11 की सच में बड़ी बात यह है कि यह सब पूरी तरह जानते हुए भी उन्होंने Stripe के अंदर वही system दोबारा बना दिया
      ऐसे comment में खर्च करने के लिए ही मैंने karma जमा करके रखा था
    • यहां link किए गए लेख की representative image तुरंत AI-generated image जैसी लगी, लेकिन मूल लेख की image को दोबारा देखने के बाद ही समझ आया कि वह भी AI-generated है
      मूल लेख की image काफी complex थी, जैसे Atlantic, Wired, New Yorker जैसी जगहों के किसी व्यक्ति ने बनाई abstract art हो, और लगभग एकमात्र clue टूटे हुए अक्षर थे। comment वाला लेख अगस्त 2023 का है, इसलिए सिर्फ कुछ महीनों के quality gap से भी काफी progress दिखती है; शायद DALL-E 3 भी हो सकता है
      या फिर images उसी source से आई हों और हर लेख के लिए अलग aesthetic चुना गया हो; जो भी हो, काफी ठीक है
    • दुनिया की समस्याएं और समाधान शायद मूल रूप से इतने जटिल हैं कि जिनके पास वह skill नहीं है, उनके पास उनसे निपटने की उम्मीद लगभग नहीं होती
      practical solution शायद Patrick को model बनाकर यह मांग करना हो कि professionals अपने से कम lucky या कम शिक्षा/ज्ञान वाले लोगों के लिए कुछ समय advocacy में लगाएं
    • मुझे Patio11 की writing पसंद है, लेकिन इस क्षेत्र की formal thinking आम तौर पर anthropology और sociology के बीच और उनके भीतर मौजूद समृद्ध subfields में की जाती है। James C. Scott भी सबसे बढ़कर anthropologist हैं
      कई तरह के social scientists ऐसे topics पर अक्सर लिखते हैं, और banking sector के बारे में मुझे ज्यादा नहीं पता, लेकिन politics, technology, society और identity जैसे तत्वों के intersections को accessible होते हुए भी detail में cover करने वाली बहुत-सी किताबें हैं
      मुझे लगता है HN readers Patio11 की writing की तरफ इसलिए खिंचते हैं क्योंकि वे technical rigor के साथ लिखते हैं, जो social scientists अक्सर अच्छी तरह नहीं कर पाते। बहुत-सा social science digital दुनिया की “अंदरूनी चीजों” के आसपास थोड़ा-थोड़ा कुतरता-सा लगता है, लेकिन cover करने को बहुत कुछ है और field भी छोटी नहीं है। इसलिए मूल sources पढ़ने पर अच्छी बातें मिलती हैं, पर जब वे मेरे काम के क्षेत्र को explain करते हैं तो कुछ हिस्से गलत जैसे दिखते हैं और frustration हो सकती है। दूसरी ओर Patrick details भी सही पकड़ते हैं और general sociology भी
      James C. Scott CIA asset भी थे। उन्हें contradictions वाला व्यक्ति कह सकते हैं, या इसे pattern भी कह सकते हैं। अच्छे anthropologists में विवादास्पद लोग हैरानीजनक रूप से ज्यादा हैं

  • लेख में reference की गई Seeing Like a State सचमुच बेहतरीन किताब है: https://www.amazon.com/Seeing-like-State-Certain-Condition/d...
    बहुत recommend करता हूं, लेकिन पहले summary सरसरी तौर पर देखकर यह confirm करना अच्छा होगा कि इसे पढ़ना enjoyable या useful लगेगा या नहीं: https://en.wikipedia.org/wiki/Seeing_Like_a_State

    • अच्छी किताब है, लेकिन analysis एक तरफ झुका हुआ है। high modernism के अच्छे से काम करने वाले cases पर किताबों के साथ पढ़ने की सलाह दूंगा, जैसे The Ghost Map: https://www.goodreads.com/book/show/36086.The_Ghost_Map
    • HN पर book links आने और local public library की borrow rate के बीच relationship map करना दिलचस्प होगा
      यहां कुछ पढ़ने लायक दिखे तो मैं आम तौर पर सबसे पहले library जाता हूं
    • मैं अभी यह किताब पढ़ रहा हूं, इसलिए सोच रहा था कि title इसी का reference है क्या; अब लेख पढ़ना पड़ेगा
    • इस किताब के बारे में बहुत अच्छी बातें सुनी हैं, लेकिन personally मुझे यह काफी disappointing लगी
    • इस topic पर काफी मजेदार video देखना हो तो: https://www.youtube.com/results?search_query=reasontv+uninte...

  • इस बात को और बेहतर तरीके से समझाना चाहता हूं: संगठन टीमों से बने होते हैं
    यह बहुत obvious लगता है, लेकिन इसका मतलब है कि कोई भी change request आखिरकार एक टीम या कई टीमों के पास ही जाती है
    बाहर से देखने पर किसी enterprise के पास practically असीमित resources लगते हैं, लेकिन अंदर से देखें तो किसी खास team के पास बहुत सीमित resources ही होते हैं। हो सकता है उस team में अभी-अभी layoffs हुए हों, उसने अपना leader खो दिया हो, या वह reorg से गुज़री हो
    “वह retail user bank account, finance overall, और अक्सर जीवन के कई पहलुओं में बेहद अनाड़ी होता है” वाला वाक्य मज़ेदार लगा

    • बड़े संगठन cost-cutting units से बने होते हैं
      मैं बड़ी कंपनियों के साथ काफी काम करता हूं, और जिस software को मैं support करता हूं उसमें लगातार problems इसलिए आती रहती हैं क्योंकि operational cost लगातार घटाने का आदेश होता है। एक team होती है जो अच्छी तरह trained होती है, software को अच्छी तरह समझती है और उसे लगभग 100% तक maintain रखती है; फिर एक दिन अचानक वह पूरी गायब हो जाती है और उसकी जगह एक overseas outsourcing team आ जाती है जिसे specialist software के बारे में कुछ भी नहीं पता। वे computer on कर लें तो भी हैरानी होती है
      software availability बहुत गिर जाती है और delivery पर सीधे असर पड़ता है, और company के हिसाब से इसकी cost कितनी पड़ती है, पता नहीं चल पाता। supplier-side support एक विशाल, महंगा mess बन जाता है, और अब “शौच के बाद flush करें और pants फिर से ऊपर करें” स्तर के instructions लिखने पड़ते हैं
    • इस बात पर मैं सचमुच इससे ज़्यादा upvote नहीं कर सकता
      संगठन के resources को teams में बांटना मूल रूप से messy और inefficient काम है, इसलिए इसे ठीक करना मुश्किल है। team बनाते समय internal politics, middle managers का ego, और individual preferences को ध्यान में रखना पड़ता है, और नतीजा अक्सर पूरे संगठन के लिए best outcome से काफी दूर होता है

  • “Ops ने सीख लिया है कि वे ऐसा software इस्तेमाल नहीं कर सकते जो broken न हो, और इसकी शिकायत करना gravity की शिकायत करने जैसा है” वाला हिस्सा सिर्फ banks में नहीं, हर जगह दिखता है
    आम workflows दर्जनों habitual workarounds की वजह से बुरी तरह टूटे होते हैं, और कई बार developer को problem का पता भर चल जाए तो वह उसे एक दिन में ठीक कर सकता है। मैंने इसे teams के बीच dependencies रखने वाली engineering teams में भी देखा है
    लोगों को इस तरह train करना कि वे अपने workflow के chronic pain को बस सहते न रहें, सचमुच मुश्किल है

    • मैं banks के साथ एक problem पर काम कर रहा हूं, जिसके बारे में बहुत detail में नहीं बता सकता। कभी-कभी उनके software workflow की problems दिखती हैं, लेकिन पैसे से direct जुड़ी न होने पर भी अक्सर final result किसी भी तरह बदलना नहीं चाहिए
      “गलत answer आ रहा है” या “हर दिन XX person-hours waste हो रहे हैं” जैसी बातें consideration में नहीं आतीं। कुछ भी बदलना नहीं चाहिए
      bank IT operations में हर department गहरे blame-avoidance mode में होता है। यह “problem ढूंढकर identify करें” mode नहीं, बल्कि “यह मेरी responsibility नहीं है” mode होता है। हमारे application की performance लगभग zero तक गिर गई थी, और disk operations प्रति minute कुछ ही रह गए थे, तब भी हमने customer से कई घंटों तक कहा कि यह infrastructure issue है
      कारण ढूंढने के लिए infrastructure teams को बुलाया, लेकिन कोई भी मददगार नहीं था; सबकी पहली बात थी “सब normal है, हमारी problem नहीं” और दूसरी थी “हमने कुछ भी नहीं बदला”
      दो दिनों में 10 घंटे की call के बाद NAS team ने माना कि उन्होंने NAS side पर antivirus चालू किया था, CPU spike कर रहा था और equipment meltdown की हालत में था। उससे पहले के लोग metrics देखे बिना ही “मेरी problem नहीं, सब normal है” जवाब दे रहे थे
    • मैं पहले एक digital media company में काम करता था। developer के नज़रिए से नए mini-site के ads set up करने की process बहुत pain थी, और ads team के साथ बहुत back-and-forth और approvals चाहिए होते थे
      दूसरे developers से पूछा तो उन्होंने कहा “यह ads team को चाहिए process है”; ads team से अलग जाकर पूछा तो उन्होंने कहा “developers को यह ऐसे चाहिए, इसलिए मजबूरी है”
      पता चला कि दोनों sides बेहतर तरीका चाहती थीं, और तीन page/ad placement templates से यह काफी आसानी से solve हो सकता था, बस वे आपस में बात नहीं कर रहे थे
    • मैं एक team को support करने वाली role में गया, जहां team को एक बेहद talented व्यक्ति से, जिसे migraine था, बहुत सारी चीजों के बारे में सुनने को मिला था कि वे “impossible” हैं
      अच्छे दिनों में वह व्यक्ति कुछ भी कर सकता था, लेकिन बुरे दिनों में बस office से लोगों को बाहर निकालना चाहता था। उसकी क्षमता साबित थी, इसलिए team उसकी बात को gospel की तरह मानती थी
      हर हफ्ते एक-दो घंटे देकर मैं कोई “impossible” चीज़ निकालता और उसे fix कर देता, और team बहुत खुश होती और मुझे wizard-level abilities वाला समझती
    • कई मामलों में normal workflow इतना documented भी नहीं होता कि उसे reproduce किया जा सके
      अक्सर तो यह identify करने लायक भी नहीं होता कि ऐसा कोई flow शुरू में exist भी करता था या नहीं
    • मेरी पिछली team में हर engineer साल में एक दिन operations person के साथ shadowing करके observe करता था। इसकी वजह से हमने सचमुच बहुत सारी चीजें fix कीं

  • “कभी-कभी hold music सुनना पड़े, फिर भी credit cards और discount brokers वाली दुनिया को prefer करना चाहिए” वाले argument में problem है
    हमें 30 साल पहले से पता था कि wait कराने वाले systems से callback systems बेहतर हैं। अगर banks ऐसी basic चीज़ भी नहीं कर सकते, तो शायद वे कभी न कभी software capability हासिल कर लेंगे, लेकिन तब तक मुझे लगता है मैं बहुत पहले मर चुका होऊंगा

    • आप कहां रहते हैं, इस पर निर्भर करता है। हमारे देश में bank की तरफ से पहले आए call पर मैं कभी सीधे भरोसा नहीं करूंगा, और हमेशा ऐसा phone number मांगूंगा जिस पर मैं खुद वापस call कर सकूं। वह भी institution का official number होना चाहिए
      phone scams बहुत widespread हैं
    • Patrick जिस unavoidable tradeoff के framing की बात करता है, वह मुझे खास convincing नहीं लगती
      मैंने दूसरे देशों में भी credit cards और discount brokers इस्तेमाल किए हैं, और मुझे लगता है US की customer service असाधारण रूप से खराब है
    • “callback system waiting system से बेहतर है”, लेकिन असल में कई customers इसे नहीं चाहते
      already connected रहना, future में किसी connection promise से ज़्यादा सुरक्षित लगता है जो कई वजहों से fail हो सकता है

  • लेख में लिखा है कि “banks एक तरह की सच्चाई, यानी ledger, को track करने में बेहद सक्षम होते हैं”, लेकिन कुछ मामलों में हैरानी की बात है कि यह भी सच नहीं है
    कम-से-कम customer के perspective से देखें तो वे ledger को इतने counterintuitive और undocumented तरीके से operate करते हैं कि बात समझ में नहीं आती। best case में भी यह bank के पक्ष में होता है
    banks को customers के बड़े पैसों की परवाह करनी चाहिए, तो क्या यह problem नहीं है? बिल्कुल problem है
    आम low-balance checking account से आगे बढ़ें तो intense competition वाली बात भी self-justification जैसी लगती है। उदाहरण के लिए FATCA ने US residents के European bank accounts operate करने में competition को practically खत्म कर दिया है, और US में financial assets को collateral रखकर loan लेने की कोशिश करें तो competition कितना है, पता चल जाएगा
    फिर भी दुनिया के सबसे बड़े mainstream banks में से एक में साल में 1–3 बार मुझे आंखें घुमाते हुए समय लगाकर खुद को “इतना ठीक है” कहकर reassure करना पड़ता है, फिर यह सोचना पड़ता है कि उस absurd चीज़ को IRS के सामने कैसे present करूंगा, tax filing के लिए notes छोड़ने पड़ते हैं, और यह record करना पड़ता है कि भूलकर दोबारा research न करनी पड़े, तब जाकर जिंदगी में लौट पाता हूं। bank के लिए वह ledger शायद अच्छी तरह reconcile हो जाता होगा

  • एक developer के तौर पर मैं सामान्य development काम के साथ-साथ लेवल 3 support जैसा काम भी कर रहा हूँ, और जिस company में technical debt और पुराने systems बहुत हैं, वहाँ अजीब exceptions या escalations संभालना चुपचाप एक तरह का मज़ा देता है
    Customers जिन चीज़ों से गुजरते हैं, उन्हें देखकर कभी-कभी गुस्सा भी आता है। Customer support वाले जब standard से हटकर cases देखते हैं तो साफ़ तौर पर confused हो जाते हैं

  • पहले मैं core banking system बेचने वाली company में काम करता था, और वह सचमुच बहुत बिखरा हुआ था
    मैंने कल्पना भी नहीं की थी कि 2023 में भी ऐसे systems चल रहे होंगे। सिर्फ़ डरावने किस्सों से एक पूरी किताब लिखी जा सकती है
    हैरानी की बात यह है कि customers को खुश करने या innovation करने में बड़ी नाकामी के बावजूद कई banks ठीक-ठाक चलते रहते हैं। Bank सचमुच “पैसा छापने का licence” हैं

    • सोच रहा हूँ कि क्या वह Metavante था

  • बड़े banks के बीच बड़े transfers में समस्या झेलते हुए मैंने यह स्थिति खुद देखी
    Branch employee को phone पर सामने वाले को अपनी पहचान साबित न कर पाते देखना मज़ेदार भी था और बेचैन करने वाला भी। उसे यह साबित करने के लिए कि वह branch के computer के सामने है, कोई one-time password share करना था, लेकिन वह microservice जो उस password को generate या deliver करती थी, down थी

    • अगर गायब one-time password का workaround कुछ ऐसा होता, “मुझ पर भरोसा करें, मैं branch manager हूँ और customer बहुत गुस्से में है”, तो यह और भी डरावना होता
      कोई काबिल ठग इसे social engineering से बहुत आसानी से exploit कर सकता था

  • मेरा मानना है कि कई banking systems इतने खराब इसलिए हैं क्योंकि bank के नज़रिए से यह ज़्यादा मायने नहीं रखता, और उल्टा उनके लिए फायदेमंद भी हो सकता है
    Bank बदलना काफ़ी मुश्किल है, और banks सच में switching को कठिन बनाने वाली रुकावटें खड़ी करते हैं। Loan shift करने पर बड़ी “re-commitment fee” लग सकती है, loan guarantee को transfer करना लगभग असंभव हो सकता है, और account details कई जगह फैली होती हैं; कुछ गलत हुआ तो payments miss हो सकते हैं
    एक अच्छा उदाहरण: Finland में जब यह proposal आया कि जैसे telecom companies को phone number transfer करने देना पड़ता है, वैसे ही bank account number भी दूसरे bank में transfer किया जा सके, तो bank lobbyists ने कहा कि यह technically impossible है। ज़ाहिर है, यह बेतुका है। और आज के दौर में भी bank transfers के settlement के लिए कई दिन इंतज़ार करना पड़ता है
    Monzo जैसे नए bank का उपयोग करके देखें तो बहुत साफ़ दिखता है कि ज़्यादातर banks बस खराब हैं
    अगर आपके पास हवा में से पैसा बनाने का licence हो, तो lobbying को छोड़कर बाकी क्षेत्रों में सचमुच incompetent होते हुए भी आप भारी पैसा कमा सकते हैं

    • अगर बात Finland के अंदर इस्तेमाल होने वाले bank account number की है, तो उसे बदला जा सकता है। नए system में national-level database होगा, जो दिखाएगा कि कौन-सा account number किस bank से जुड़ा है
      लेकिन accounts के पास IBAN number भी होता है, और उसमें country और bank/institution identifier शामिल होता है। Customer अगर bank बदलता है, तो international financial law न बदलने तक वह number बदलना ही पड़ेगा
      जहाँ तक मुझे पता है, IBAN लगभग हर जगह व्यापक रूप से इस्तेमाल होता है। इसलिए यह समस्या को सच में हल नहीं करेगा, बस complexity की एक और layer जोड़ देगा
    • Phone number portability से तुलना बहुत सही नहीं बैठती
      Phone numbers को सभी telecom operators में unique होना mandatory है, इसलिए portability संभव है। Bank account numbers हर bank के internal numbers होते हैं और कई arbitrary factors के आधार पर बनाए जाते हैं
      अगर जिस bank में मैं जाना चाहता हूँ, वहाँ मेरे पुराने bank वाले account number के समान number वाला account पहले से मौजूद हो, तो यह कैसे काम करना चाहिए?
    • “हवा में से पैसा बनाने का licence” वाली अभिव्यक्ति fractional reserve banking की एक आम लेकिन थोड़ी misleading व्याख्या है
      अगर मैं आपको 100 dollars उधार दूँ, और आप वही 100 dollars किसी और को उधार दें, तो monetary sense में आपने “100 dollars create” किए। लेकिन accounting के perspective से यह हवा से नहीं आया, बल्कि debt एक व्यक्ति से दूसरे व्यक्ति तक गया है
    • Netherlands में banks के बीच “bank switching” service (https://www.overstapservice.nl/, Dutch) है, इसलिए जब आप दूसरे bank में जाते हैं तो पुराने bank में आने वाले transfers और direct debits अपने आप नए account में forward हो जाते हैं
      नया bank companies को आपका नया account बता भी सकता है, और वे companies अपने systems में account number बदल देती हैं
      ऐसी service का होना और widely used होना अच्छा है, लेकिन इसने banks को बुनियादी तौर पर कम खराब नहीं बनाया
      निष्कर्षतः personal current accounts banks के लिए आम तौर पर loss-leader products जैसे होते हैं। इसलिए cost cutting, जैसे tiered support system, बहुत important है। असली पैसा दूसरे products—loans और mortgages, खासकर corporate customers—से बनता है
    • हवा में से पैसा बनाने से ज़्यादा यह ऐसा है कि वे एक ऐसी निश्चित रकम lend कर सकते हैं जो उनके पास नहीं है, और उम्मीद करते हैं कि वह ब्याज सहित वापस मिलेगी