Citibank'ın 900 milyon dolarlık hatası: Revlon ödemesi ve tek bir kutu

• Birincil kaynak, ABD New York Güney Bölge Mahkemesi'nin 16 Şubat 2021 tarihli kararı. Yargıç Jesse M. Furman.
• Citibank yaklaşık 7,8 milyon dolar faiz göndermek istedi. Buna ek olarak kendi parasından neredeyse 900 milyon dolar gitti.
• Kılavuza göre üç alan işaretlenmeliydi: FRONT, FUND ve PRINCIPAL. Yalnızca PRINCIPAL işaretlendi.
• Üç kişilik onay hatayı yakalamadı. Son uyarı, gidecek tutarı göstermiyordu.

Ne oldu: 11 Ağustos 2020

Citibank, Revlon'un 2016'da aldığı 1,8 milyar dolarlık, yedi yıl vadeli sendikasyon kredisinde idari temsilciydi. Görevi, Revlon'dan gelen faiz ve anapara ödemelerini kredi verenlere aktarmaktı.

11 Ağustos 2020'de bir "roll-up" işlemi vardı. Beş kredi veren, 2016 kredisindeki paylarını Revlon'un başka bir kredisindeki paylarla değiştiriyordu. Kredi, kalan kredi verenlerle yeniden kurulacaktı. Karara göre bunu Flexcube'da yapmanın en kolay, belki de tek yolu, krediyi tamamen kapatıyormuş gibi girmekti.

Plan şuydu: herkese birikmiş faiz gidecek, anapara ise "wash account" denen bir iç hesaba yazılacaktı. Bu hesap, paranın bankadan çıkmadığı muhasebe kayıtları için kullanılıyordu.

Ekran ve kılavuz

Flexcube'da girilen her ödeme, varsayılan olarak havale diye bankadan çıkıyordu. Karar bunun sebebini de yazıyor: işlemlerin büyük çoğunluğu zaten üçüncü kişilere ödemeydi.

Varsayılanı durdurmak için ekranda bir menü vardı. Her satırda bir bileşen adı, bir hesap alanı ve bir onay kutusu duruyordu. Bankanın iç kılavuzu, anaparayı durdurmak için FRONT, FUND ve PRINCIPAL alanlarının üçünün de iç hesaba ayarlanmasını istiyordu.

İşlemi hazırlayan çalışan, akşam 17.15 ile 17.45 arasında yalnızca PRINCIPAL kutusunu işaretledi. Karara göre işleme bakan üç kişi de yalnızca bu alanın yeteceğine inanıyordu.

Altı göz

İşlem, bankanın "six-eye" (altı göz) dediği onay sürecine tabiydi. Üç kişi işlemi sırayla inceleyip onaylamadan para çıkmıyordu.

1. 1. Hazırlayan

   Ödemeyi Flexcube'a girer. Yalnızca PRINCIPAL kutusunu işaretler.

2. 2. Kontrol eden

   İşlemi inceler. Anaparanın iç hesaba gideceğine inanır.

3. 3. Onaylayan

   E-postayla onay verir: "Looks good, please proceed."

4. 4. Dur işareti

   "Para bankadan çıkacak" der. Tutarı göstermez. Cevap: "YES".

5. 5. Sonuç

   Faize ek olarak yaklaşık 894 milyon dolar anapara kredi verenlere gider.

Şekil: Karardaki olay sırasına göre benim çizimim. Kişileri adlarıyla değil, rolleriyle yazdım.

Kontrol eden kişi son adımda ekranında bir uyarı gördü. Karar buna "stop sign" (dur işareti) diyor. Metin kabaca şuydu: kullanılan hesap bir havale hesabı, para bankadan çıkacak, devam etmek istiyor musunuz?

Karar, uyarının neyi göstermediğini de açıkça yazıyor. Uyarı, ne kadar paranın çıkacağını söylemiyordu. Giden paranın faiz mi anapara mı olduğunu da belirtmiyordu. Faizin çıkması zaten beklendiği için cevap "YES" oldu.

Ertesi sabah

Akşam 18.53'te hazırlayan kişi, işlemin ekran görüntülerini kontrol eden kişiye gönderdi. Görüntülerde "Amount Paid" alanında 7,8 milyon dolar faiz ve 894 milyon dolar anapara görünüyordu. Kontrol eden kişi anaparanın iç hesaba "ödendiğini" düşündü ve bir sorun görmedi.

Hata 12 Ağustos sabahı, günlük mutabakat kontrolünde ortaya çıktı. Onaylayan yönetici önce yazılımda bir arıza olduğunu düşündü ve ekibine "Urgent Wash Account Does not Work" başlıklı bir e-posta yazdı.

Gün içinde sebebin bir arıza olmadığı anlaşıldı. Karara göre sebep insan hatasıydı: FRONT ve FUND alanları seçilmemişti. 315 kredi veren, 893.944.008,52 dolarlık anaparadan payını almıştı.

Ekran rekonstrüksiyonu: tek kutuyu siz işaretleyin

Kararda ekranın bir görüntüsü var (Şekil 1). Satırlarda bileşen adları, yanlarında hesap alanları ve "Overwrite default settlement instruction" başlıklı bir kutu sütunu görünüyor. İşaretli tek kutu PRINCIPAL satırında.

Aşağıdaki demo bu ekranı birebir kopyalamıyor. Kararın anlattığı kuralı kurgusal bir ekranda canlandırıyor. Önce "Kararda tarif edilen mantık" ile onaylayın, sonra "Önerdiğim tasarım"a geçip aynı kutularla tekrar deneyin.

İlk ekranda kutular size bir şey söylüyor: PRINCIPAL iç hesaba gidiyor. Bu doğru, ama eksik. Ekran, diğer iki alanın boş kalmasının ne anlama geldiğini söylemiyor.

İkinci ekranda aynı kutular duruyor. Fark, ekranın sonucu sizin yerinize toplaması. Toplam tutar her kutu değiştiğinde güncelleniyor. Anapara çıkacaksa düğme, siz bunu bildiğinizi işaretleyene kadar kapalı kalıyor.

FRONT ve FUND kutularını da işaretleyip tekrar deneyin. Benim canlandırmamda ilk ekranın dur işareti yine aynı cümleyi söylüyor, çünkü faiz hâlâ bankadan çıkıyor. Doğru talimatla yanlış talimat arasında, onay anında hiçbir fark görünmüyor.

İkinci ekranda ise toplam 7,8 milyon dolara düşüyor ve uyarı kayboluyor. Kullanıcı aynı kutularla çalışıyor ama sonucu kendi gözüyle görüyor. Kontrol eden ve onaylayan kişi de aynı özeti görürse, üç göz çifti aynı sayıya bakmış olur.

Ben burada yeni bir kural eklemedim. Kılavuzdaki kural zaten vardı. Yaptığım tek şey, kuralın sonucunu ekrana yazmak.

Ne biliyoruz, ne bilmiyoruz

Bu sayfadaki olay anlatımı iki mahkeme kararına dayanıyor. Tabloda neyin kararda yazdığını, neyin yazmadığını ayırdım.

Yargıç Furman kararın girişinde olayı "bankacılık tarihinin en büyük gaflarından biri" diye niteliyor. Kararın aynı bölümüne göre ödenen tutarlar, Revlon'un kredi verenlere borçlu olduğu anapara ve faizle kuruşu kuruşuna eşitti.

Karar, giden anapara için "almost $900 million" ifadesini kullanıyor. Tam rakam 893,9 milyon dolar.

Hukuki sonuç

Yargıç Furman, 16 Şubat 2021'deki kararında parayı iade etmeyen kredi verenlerin haklı olduğuna hükmetti. Gerekçe, New York hukukundaki "discharge-for-value" kuralıydı: ödeme borcu kuruşu kuruşuna karşılıyordu ve alıcılar hatadan haberdar değildi.

Citibank temyize gitti. ABD 2. Daire Temyiz Mahkemesi 8 Eylül 2022'de kararı bozdu ve davayı geri gönderdi. Mahkemeye göre alıcılar hatadan haberdar sayılırdı. Kredi de o tarihte henüz ödenebilir değildi, vadesine üç yıl vardı.

Bu bölüm bir özettir, hukuki danışmanlık değildir.

Benim notum

Bu vakayı audit'lerde sık anlatırım, çünkü suçu kişilerde aramak çok kolay. Üç deneyimli kişi aynı yanlış inancı paylaştıysa, sorun inançtan çok ekrandadır. Ekran, kutuyu işaretleyen kişiye "tamam" hissi veriyordu. Sonucu ise söylemiyordu.

Bence asıl ders şu: tehlikeli bir eylemin onay ekranı, eylemin sonucunu sayıyla göstermeli. "Para bankadan çıkacak" bir cümle. "901,7 milyon $ bankadan çıkacak" ise bir karar anı. İnsan ikincisinde durur.

Varsayılan ayar da işin içinde. Burada boş kalan her kutu parayı dışarı gönderiyordu, yani en pahalı sonuç varsayılandı. Varsayılanı değiştiremiyorsanız, özet ekranı bunun ne yapacağını açıkça yazmalı.

Kılavuzdaki kontrol listesini de ekrana taşırdım. Üç alan birlikte işaretlenmeliyse ekran bunu tek seçenekte toplayabilir: "Anaparayı iç hesapta tut." Kullanıcı niyetini seçer, alanları sistem doldurur.

Kendi ürününüzde nasıl kontrol edersiniz

Bu hatanın küçük kopyaları bankacılığın dışında da var. E-ticaret panelindeki toplu iade ya da SaaS ürünündeki "tüm kayıtları sil" düğmesi aynı riski taşır.

• Geri alınamaz her eylemden önceki onay ekranı, etkilenecek tutarı ya da kayıt sayısını gösteriyor mu?
• Uyarı metni beklenen durumda da aynı mı? Her seferinde çıkan uyarı, bir süre sonra okunmaz.
• Birlikte değişmesi gereken alanlar ekranda tek bir seçenek mi, yoksa kılavuzdaki bir kural mı?
• Onaylayan kişi, hazırlayanın gördüğü ekranı mı görüyor, yoksa yalnızca onun e-postadaki özetini mi?

Son madde bu vakada önemliydi. Karara göre onay e-postaları anaparanın iç hesaba gittiğini yazıyordu: "Principal set to Wash", "Principal is going to wash". E-postalar ekibin inancını tekrarlıyordu. Ekranın gerçekte yapacağı şey ise başkaydı.

Uyarı metinleri için hata mesajları kalıbına, finans ürünlerindeki riskli akışlar için fintech UX rehberine bakabilirsiniz. Ekiplerin ekranı farklı anlamasını zihinsel model sayfasında anlattım. Hatayı baştan önleyen ekran ilkeleri için Nielsen'in 10 ilkesi sayfasına bakın.

Ürününüzdeki geri alınamaz akışları benim incelememi isterseniz, UX Audit tam bunun için var.