2026’da kurumsal ödeme güvenliğinde en pahalı hata hâlâ aynı yerden çıkıyor: IBAN değişikliği. Sorun teknoloji değil; onayın mimarisi. Tek imza, tek e-posta, tek mesaj… Hepsi saldırganın sevdiği zemin.

Bu yazıda, IBAN değişimini kilitleyen ve denetimde savunulabilir kılan 2 katmanlı onay mimarisini net biçimde anlatıyoruz ve tek sayfa, kopyalanabilir bir şablon veriyoruz.

Onay Mimarisi Nedir?

Onay mimarisi; hangi değişikliğin, kim tarafından, hangi kanaldan ve kaç adımda onaylanacağını önceden tanımlayan kural setidir. Amaç hız değil, yanlış hızı durdurmaktır.

2026 gerçeği:
IBAN değişikliği istisnadır. İstisna, istisna prosedürü ister.

Neden IBAN Değişikliği En Zayıf Halka?

• BEC/CEO dolandırıcılığı en sık buradan vurur.
• “Acil” ve “gizli” diliyle süreç baypas edilir.
• Görünürde küçük bir değişiklik, geri dönüşsüz para çıkışı üretir.

2 Katmanlı Prosedür: Mantık ve Akış

Katman 1 — Kimlik ve Kanal Doğrulaması

Amaç: Talebin gerçek kişi/kurumdan geldiğini kanıtlamak.

Zorunlu kurallar

• Talep tanımlı kanaldan gelir (kurumsal e-posta/portal).
• İkinci kanal teyidi yapılır (kurumsal hat).
• Gönderici alan adı ve “reply-to” kontrol edilir.
• Değişiklik talebi yazılı alınır (ekran görüntüsü değil).

Alarm: “Toplantıdayım”, “şimdi yap”, “kimseye söyleme”.

Katman 2 — Zaman Kilidi ve Çift Onay

Amaç: Aceleyi söndürmek, hatayı yakalamak.

Zorunlu kurallar

• Bekleme süresi: 24–48 saat (istisnasız).
• Çift onay: Talep onayı + uygulama onayı (iki farklı rol).
• Küçük test ödemesi (mümkünse) veya ilk ödeme kısıtı.
• Yetki matrisi ile tutar sınırı.

Kural: Zaman kilidi yoksa, güvenlik yoktur.

Tek Sayfa Şablon — IBAN Değişikliği Onay Formu (Kopyala–Kullan)

Belge Adı: IBAN Değişikliği Talep ve Onay Formu
Versiyon/Tarih: v1.0 / ………

A) Talep Bilgileri

• Tedarikçi/Alıcı Ünvanı:
• Mevcut IBAN:
• Yeni IBAN:
• Değişiklik Gerekçesi:
• Talep Kanalı: (Kurumsal e-posta / Portal)
• Talep Tarih-Saat:

B) Katman 1 — Kimlik & Kanal Doğrulaması

• Alan adı / gönderici kontrolü yapıldı mı? ☐ Evet ☐ Hayır
• İkinci kanal teyidi alındı mı? ☐ Evet ☐ Hayır
• Teyit Kanalı: (Kurumsal hat)
• Teyit Eden:
• Teyit Tarih-Saat:
• Şüpheli dil/acele baskısı var mı? ☐ Yok ☐ Var (Açıkla)

Katman 1 Onayı (İsim-İmza-Tarih):
……………………………………

C) Katman 2 — Zaman Kilidi & Çift Onay

• Bekleme Süresi: ☐ 24s ☐ 48s (Başlangıç: … / Bitiş: …)
• Yetki Matrisi Uygunluğu: ☐ Uygun ☐ Değil
• Test/Kısıt Uygulandı mı? ☐ Evet ☐ Hayır (Açıkla)

Uygulama Onayı (İsim-İmza-Tarih):
……………………………………

D) Son Kontrol (Ödeme Öncesi)

• Alıcı adı–IBAN eşleşmesi ☐
• Açıklama standardı ☐
• İlk ödeme tutar kısıtı ☐

Ödeme Serbest Bırakma (İsim-İmza-Tarih):
……………………………………

30 Saniyelik Alarm Testi

Aşağıdakilerden iki tanesi varsa dur:
1) Kanal dışı talep
2) Acil/gizli dil
3) IBAN + alıcı adı uyumsuz
4) Bekleme süresi atlanmak isteniyor
5) Tek kişinin “tamam”ı isteniyor

En Sık Yapılan 5 Hata

• ❌ WhatsApp talimatını yazılı saymak
• ❌ Zaman kilidini “istisna” diye kaldırmak
• ❌ Aynı kişinin iki onayı vermesi
• ❌ İlk ödemede tutar kısıtı koymamak
• ❌ Yetki matrisini güncellememek

Denetimde Savunma Cümlesi

“IBAN değişiklikleri iki katmanlı onay ve zaman kilidi olmadan uygulanmaz.”

Bu cümle, uzun açıklamalardan daha güçlüdür.

2026’da güvenli ödeme; filtre değil, mimari işidir.
IBAN değişikliği küçük bir güncelleme değil, yüksek riskli bir istisnadır.

Sessiz güç burada başlar:
onayı hızlandırmakta değil, doğru yerde yavaşlatmakta.