アルゼンチンのCBUジェネレーター&バリデーター | BCRA銀行コード
テスト用に有効なアルゼンチンのCBU(統一銀行コード)を生成するか、既存の22桁の銀行コードが中央銀行BCRAの定める検証式に合格するかどうかを確認する無料ツール。開発者やテスターが金融アプリの動作確認をする際に、迅速かつ正確に、追加費用や登録なしですぐ利用できる。
アルゼンチンCBUジェネレーター&バリデーター
アプリケーションや統合をテストするためのランダムで有効なCBUを生成します。
上のボタンをクリックして有効なCBUを生成
CBUについて
CBU(Clave Bancaria Uniforme)は、電子送金や支払いのためにアルゼンチンで使用される22桁のコードです。
各CBUには、銀行、支店、口座番号に関する情報と、その有効性を保証する検証数字が含まれています。
CBUの構造
ドキュメンテーション
アルゼンチンのCBUとは何か、なぜ検証するのか
アルゼンチンの銀行システムを扱う際は、CBU(Clave Bancaria Uniforme)—国内のすべての銀行口座を一意に識別する22桁のコードに対処する必要があります。支払い統合をテストしたり、送金前に銀行詳細を確認したり、トランザクションが失敗した理由を理解したりする必要がある場合、適切にフォーマットされたCBUを扱うことがいかに重要かわかるでしょう。
このツールは、テスト環境で構造的に有効なCBUを生成し、アルゼンチン中央銀行(BCRA)が指定する公式フォーマットに対して既存のコードを検証するのに役立ちます。金融アプリケーションを構築したり、支払いを処理したりする際、早期にフォーマットエラーを捉えることで、何時間もかかるデバッグを節約し、トランザクションの失敗を防ぐことができます。
CBUフォーマットの理解
CBU(Clave Bancaria Uniforme)は、IBANや米国の口座番号のような国際的な銀行識別子に対するアルゼンチンの解決策です。これは、銀行、支店、口座情報を1つの22桁のコードにまとめた包括的なパッケージと考えてください。アルゼンチン中央銀行(BCRA)は、2000年11月にこのシステムを導入し、国の金融ネットワーク全体の電子送金を標準化しました。
CBUの構造と形式
有効なCBUは、2つの主要なブロックに分割された正確に22桁で構成されています:
-
第1ブロック(8桁): 金融機関と支店を識別
- 最初の3桁: BCRAによって割り当てられた銀行コード
- 次の4桁: 銀行内の支店コード
- 最後の1桁: 第1ブロックの検証数字
-
第2ブロック(14桁): 特定の口座を識別
- 最初の13桁: 口座番号(口座種別やその他の識別子を含む場合がある)
- 最後の1桁: 第2ブロックの検証数字
検証数字は、重み付けモジュロ-10アルゴリズムを使用し、お金が動く前に、桁の入れ替えや1桁のエラーなどの一般的な入力ミスを検出します。この安全策は非常に効果的で、ほとんどのCBU入力エラーは転送失敗ではなく、検証段階で捕捉されます。
テスト用CBUの生成方法
ジェネレーターは、すべての形式チェックを通過する構造的に有効なランダムなCBUを作成します。裏側では以下のことが行われています:
- ランダムな数字が銀行コード、支店コード、口座番号のセクションに入力されます
- ツールは公式のBCRAアルゴリズムを使用して、両方の検証数字を計算します
- テスト用に使える、適切にフォーマットされた22桁のCBUが生成されます
このツールが役立つ場面:
- 決済統合のテスト: テストスイートに必要な数十の有効なCBUをすぐに生成できます。手動計算の必要がありません。
- QAおよびステージング環境: 実際の口座と偶然一致しない、現実的な銀行データでテストデータベースを埋めることができます。
- フォーマットの学習: さまざまなCBUの構造を確認し、検証ロジックを理解できます。
- ドキュメントとデモ: 実際の銀行情報を公開せずに、本物らしいサンプルデータを作成できます。
ステップバイステップ:CBUの生成
- ツールの「ジェネレーター」タブに移動します
- 「CBU生成」ボタンをクリックします
- 有効なランダムな22桁のCBUが表示エリアに表示されます
- 「コピー」ボタンを使用して、アプリケーションで使用するCBUをクリップボードにコピーします
アルゼンチンCBUの検証方法
バリデーターは、アルゼンチンの銀行システムがCBUの整合性を確認するのと同じチェックを実行します。チェックされる内容は以下の通りです:
- 長さの確認: 正確に22桁であることを確認(スペースやハイフンを含めて誤ってコピーすることがよくある間違い)
- 数字のみの内容: 文字や特殊文字が紛れ込んでいないことを確認
- 最初のブロックのチェックサム: 8桁目を最初の7桁に対して検証
- 2番目のブロックのチェックサム: 22桁目を9-21桁に対して検証
検証に失敗した場合、どの特定のチェックが通過しなかったかが表示されます。これは、銀行APIがCBUを拒否した理由をデバッグする際に特に役立ちます。多くの場合、余分なスペースや桁の入れ替えなど、単純な問題が原因です。
ステップバイステップ:CBUの検証
- ツールの「バリデーター」タブに移動
- 検証したい22桁のCBUを入力
- 「CBUを検証」ボタンをクリック
- 検証結果を確認:
- 有効なCBUには緑色のインジケーター
- 無効なCBUには特定のエラーメッセージと赤色のインジケーター
CBU検証アルゴリズムの説明
BCRAは、検証桁を計算するために重み付きモジュロ-10チェックサムアルゴリズムを使用しています。アプリケーションでCBU検証を実装する場合、以下が正確なロジックです:
第1ブロックの検証
第1ブロック(最初の8桁)の検証桁は、次のように計算されます:
- CBUの最初の7桁を取得
- 各桁を対応する重み [7, 1, 3, 9, 7, 1, 3] で乗算
- 結果の積を合計
- 計算: 10 - (合計 % 10)
- 結果が10の場合、検証桁は0;そうでない場合は、計算された値
第2ブロックの検証
第2ブロック(最後の14桁)の検証桁は、次のように計算されます:
- 第2ブロックの最初の13桁を取得
- 各桁を対応する重み [3, 9, 7, 1, 3, 9, 7, 1, 3, 9, 7, 1, 3] で乗算
- 結果の積を合計
- 計算: 10 - (合計 % 10)
- 結果が10の場合、検証桁は0;そうでない場合は、計算された値
CBU検証コードの例
アプリケーションでCBU検証を実装する方法を以下に示します。これらの例は、公式のBCRA仕様に従っており、実稼働の銀行データで動作します:
1// JavaScript: CBUチェックディジットの計算
2function calculateCheckDigit(number, weights) {
3 if (number.length !== weights.length) {
4 throw new Error('数値の長さは重みの長さと一致する必要があります');
5 }
6
7 let sum = 0;
8 for (let i = 0; i < number.length; i++) {
9 sum += parseInt(number[i]) * weights[i];
10 }
11
12 const remainder = sum % 10;
13 return remainder === 0 ? 0 : 10 - remainder;
14}
15
16// CBUの最初のブロックを検証
17function validateFirstBlock(block) {
18 if (block.length !== 8 || !/^\d{8}$/.test(block)) {
19 return false;
20 }
21
22 const number = block.substring(0, 7);
23 const checkDigit = parseInt(block[7]);
24 const weights = [7, 1, 3, 9, 7, 1, 3];
25
26 return checkDigit === calculateCheckDigit(number, weights);
27}
281# Python: 完全なCBUを検証
2import re
3
4def validate_cbu(cbu):
5 # 基本的な形式をチェック
6 if not cbu or not re.match(r'^\d{22}$', cbu):
7 return {
8 'isValid': False,
9 'errors': ['CBUは22桁である必要があります']
10 }
11
12 # ブロックに分割
13 first_block = cbu[:8]
14 second_block = cbu[8:]
15
16 # 各ブロックを検証
17 first_block_valid = validate_first_block(first_block)
18 second_block_valid = validate_second_block(second_block)
19
20 errors = []
21 if not first_block_valid:
22 errors.append('最初のブロック(銀行/支店コード)が無効です')
23 if not second_block_valid:
24 errors.append('2番目のブロック(口座番号)が無効です')
25
26 return {
27 'isValid': first_block_valid and second_block_valid,
28 'errors': errors
29 }
301// Java: ランダムな有効なCBUを生成
2import java.util.Random;
3
4public class CBUGenerator {
5 private static final Random random = new Random();
6
7 public static String generateCBU() {
8 // 最初の7桁(銀行と支店コード)を生成
9 StringBuilder firstBlockBase = new StringBuilder();
10 for (int i = 0; i < 7; i++) {
11 firstBlockBase.append(random.nextInt(10));
12 }
13
14 // 最初のブロックのチェックディジットを計算
15 int[] firstBlockWeights = {7, 1, 3, 9, 7, 1, 3};
16 int firstBlockCheckDigit = calculateCheckDigit(
17 firstBlockBase.toString(),
18 firstBlockWeights
19 );
20
21 // 2番目のブロックの最初の13桁を生成
22 StringBuilder secondBlockBase = new StringBuilder();
23 for (int i = 0; i < 13; i++) {
24 secondBlockBase.append(random.nextInt(10));
25 }
26
27 // 2番目のブロックのチェックディジットを計算
28 int[] secondBlockWeights = {3, 9, 7, 1, 3, 9, 7, 1, 3, 9, 7, 1, 3};
29 int secondBlockCheckDigit = calculateCheckDigit(
30 secondBlockBase.toString(),
31 secondBlockWeights
32 );
33
34 // すべての部分を結合
35 return firstBlockBase.toString() + firstBlockCheckDigit +
36 secondBlockBase.toString() + secondBlockCheckDigit;
37 }
38
39 // calculateCheckDigitメソッドの実装...
40}
411// PHP: 表示用にCBUをフォーマット
2function formatCBU($cbu) {
3 if (!$cbu || strlen($cbu) !== 22) {
4 return $cbu;
5 }
6
7 // フォーマット: XXXXXXXX XXXXXXXXXXXXXX
8 return substr($cbu, 0, 8) . ' ' . substr($cbu, 8);
9}
10
11// 使用例
12$cbu = '0123456789012345678901';
13echo formatCBU($cbu); // 出力: 01234567 89012345678901
141' Excel VBA: CBUを検証
2Function ValidateCBU(cbu As String) As Boolean
3 ' 長さをチェック
4 If Len(cbu) <> 22 Then
5 ValidateCBU = False
6 Exit Function
7 End If
8
9 ' すべての文字が数字であることをチェック
10 Dim i As Integer
11 For i = 1 To Len(cbu)
12 If Not IsNumeric(Mid(cbu, i, 1)) Then
13 ValidateCBU = False
14 Exit Function
15 End If
16 Next i
17
18 ' ブロックを抽出
19 Dim firstBlock As String
20 Dim secondBlock As String
21 firstBlock = Left(cbu, 8)
22 secondBlock = Right(cbu, 14)
23
24 ' 両方のブロックを検証
25 ValidateCBU = ValidateFirstBlock(firstBlock) And ValidateSecondBlock(secondBlock)
26End Function
27CBU検証の実世界のユースケース
決済統合のテスト
フィンテックアプリケーションや、アルゼンチンの決済を処理する電子商取引プラットフォームを構築する際、テスト環境で有効なCBUが必要です。一般的なシナリオ:ステージング環境で、負荷テストのために50の有効なCBUテストアカウントが必要です。各アカウントのチェックディジットを手動で計算すると何時間もかかりますが、ジェネレーターは数秒でこれを処理し、本番のCBUのように動作する適切にフォーマットされたテストデータを提供し、実際の口座番号を誤って使用するリスクを回避できます。
プロのヒント: 生成されたCBUのセットをテスト用フィクスチャに保持してください。これにより、チーム全体で一貫したテストデータを確保し、テスト失敗時のデバッグを容易にします。
トランザクションエラーの防止
典型的な状況:クライアントが送金用のCBUを提供しますが、誤って空白を含めたり、2桁を入れ替えたりしています。検証せずに送金を処理すると、銀行は遅延後にのみ拒否し、すでにシステムにトランザクションの意図を記録してしまっています。これにより、調整の頭痛が発生します。
送信前にCBU形式を検証することで、これらのエラーを即座に捉えることができます。バリデーターは、口座が存在するかや正しい人に属しているかを確認できませんが(これには銀行APIへのアクセスが必要)、BCRAの基準に従って構造が正しいことを確認できます。
銀行統合要件の理解
アルゼンチンの金融システムに不慣れな開発者にとって、このツールは実践的な学習を提供します。チェックディジットの仕組みを正確に理解し、特定の番号が無効である理由を把握し、本番コードを作成する前にエッジケースを実験できます。
よくある間違い: CBUバリデーションがIBANバリデーションと同じであると思い込むこと。両方ともチェックディジットを使用しますが、アルゴリズムは完全に異なります。このツールでテストすることで、アルゼンチンの銀行コードの特定の要件を理解できます。
銀行UIのフォーム検証
CBUを受け入れる入力フォームを設計する際、システムがさまざまなエラー状態をどのように処理するかをテストする必要があります。ユーザーが空白を含むCBUを貼り付けた場合、どうなりますか?チェックディジットが間違っている場合、どのようなエラーメッセージが表示されますか?このツールは、これらのシナリオをテストし、より良いユーザーフィードバックを設計するのに役立ちます。
関連する銀行検証ツール
要件に応じて、以下の補完的なツールも必要になるかもしれません:
- CUIT/CUIL バリデータ: アルゼンチンの税務識別番号を検証—銀行と税務IDの両方を確認する必要がある場合に不可欠
- CVU バリデータ: CBUと同様ですが、デジタルウォレット(メルカドパゴ、ウアラーなど)向けの22桁のフォーマットを使用
- IBAN バリデータ: ヨーロッパやその他の国際的な口座を含む国境を越えた支払いのため
- 銀行API サービス: 単なるフォーマット検証だけでなく、口座所有権や残高確認が必要な本番システム向け
重要な制限: このツールは、フォーマットとチェックディジットのみを検証します。CBUが有効な銀行口座に対応しているかどうか、または口座名義人の身元を確認することはできません。これらの確認には、アルゼンチンの銀行APIや決済プロセッサとの統合が必要です。
アルゼンチンの銀行システムがCBUを採用した経緯
2000年11月以前、アルゼンチンの銀行間での送金は驚くほど複雑でした。各金融機関は独自の口座番号システムを使用しており、10桁の銀行もあれば15桁の銀行もあり、どの銀行やどの支店が口座を保有しているかを特定する標準化された方法はありませんでした。銀行間送金には手動での確認が必要で、処理に数日かかることもありました。
BCRAはこの分断を解決するためにCBUを導入しました。すべての金融機関に22桁の統一フォーマットを義務付けることで、アルゼンチンはヨーロッパのIBANシステムなどの国際基準に沿いました。埋め込まれたチェックディジットは特に賢明でした。ほとんどのデータ入力エラーを自動的に検出し、失敗した送金と、その調査および取り消しに関連するコストを削減しました。
興味深いポイント: CBUフォーマットは20年以上ほとんど変更されていません。モバイルアプリ、即時送金、デジタルウォレットなど、銀行技術は劇的に進化しましたが、基本的なCBU構造は同じままです。これは、元の設計が将来のニーズを如何に的確に予測していたかを物語っています。
現在、アルゼンチン人は事実上すべての電子金融取引にCBUを使用しています:給与振込、請求書支払い、税務申告、政府給付、電子商取引などです。このフォーマットは非常に効果的であることが証明されており、デジタルウォレット(メルカドパゴなど)が登場した際も、規制当局は新しいものを発明するのではなく、同じ構造のCVU(Clave Virtual Uniforme)を採用しました。
よくある質問
CBUとCVUの違いは何ですか?
CBUは従来の銀行口座を識別し、CVU(Clave Virtual Uniforme)はメルカドパゴ、ウアラー、ブルーバンクなどのフィンテック企業のデジタルウォレット口座を識別します。フォーマットは同一で、22桁で同じ検証アルゴリズムを使用しており、相互運用可能なため、CBUからCVUへ、またはその逆に送金できます。最初の3桁で、従来の銀行かデジタルウォレットプロバイダーかを判断できます。
CBUから銀行名を知ることはできますか?
はい。最初の3桁はBCRAによって割り当てられた銀行識別子です。例えば、「011」で始まるコードはバンコ・ナシオンに、「017」はBBVAアルゼンチンを示します。BCRAは公式のレジストリを公開しており、銀行アプリケーションは通常これを参照してCBUを入力すると自動的に銀行名を表示します。
CBUは口座番号と同じですか?
そうではありません。口座番号はCBU内に埋め込まれていますが、CBUはそれに追加のルーティング情報を付加しています。住所とGPS座標の違いと同じようなものです。両方が場所を特定しますが、一方はより多くのコンテキストを含みます。CBUは、銀行コード、支店コード、口座番号、2つの検証桁を1つの転送可能な文字列にまとめています。
CBUを共有することは安全ですか?
CBUは共有するために設計されています。それが目的です。受取人は口座に入金するためにそれを必要とします。パスワードやPINとは異なり、CBUは入金のみを許可し、引き出しはできません。とはいえ、他の金融情報と同様に扱い、信頼できる人や企業とのみ共有し、オンラインで公開することには注意が必要です。一部の人々は、公開的に共有するよりも選択的にCBUを提供することを好みます。
CBUは期限切れや変更されることはありますか?
口座が開いている限り、CBUはそのままです。変更されるのは、その口座を閉じて新しい口座を開く場合、または銀行が合併したり番号システムを再構築したりするまれなケースのみです。そのような場合でも、銀行は通常、定期的な支払いを中断しないよう、一定の移行期間は古いCBUを維持します。
自分のCBUを見つける方法は?
銀行のモバイルアプリで確認できます。通常、口座詳細セクションにあります。ほとんどのアルゼンチンの銀行はオンラインバンキングでも目立つように表示し、月次明細書に印刷し、一部のデビットカードの裏面にも記載しています。見つからない場合は、銀行の担当者がすぐに提供できます。PINのような機密情報とは見なされません。
外国人はアルゼンチンでCBUを持てますか?
はい。アルゼンチンで銀行口座を開設すれば、他の口座保有者と同様にCBUが付与されます。要件は銀行によって異なり、パスポートのみを要求する銀行もあれば、居住証明やCDI(税務識別番号)を求める銀行もあります。デジタルウォレット(CVU)は、従来の銀行口座よりも外国人が取得しやすいことが多いです。
無効なCBUに送金するとどうなりますか?
最新の銀行システムは、送信前に形式検証を実行します。チェックディジットが一致しないか、長さが正しくない場合、即座にエラーが発生し、送金は口座から出ません。これが、フロントエンド検証が非常に価値がある理由です。タイプミスを事前に防ぐことができます。
より厄介なのは、形式検証を通過しても、アクティブな口座と一致しない場合です。送金は銀行間ネットワークに送信され、数時間または数日後に戻ってきます。すでに「送信済み」として会計処理されているため、返金の調整が必要になります。そのため、一部のアプリケーションは、送金を許可する前にCBUを銀行データベースに対してチェックしますが、これには有料APIアクセスが必要です。
複数のCBUを持つことはできますか?
可能です。各口座は独自のCBUを生成します。同じ銀行で当座預金口座と普通預金口座を持っている場合、2つの異なるCBUがあります。異なる銀行の異なる口座なら、さらに多くのCBUがあります。それぞれが特定の金融機関の特定の支店の特定の口座を一意に識別します。
CBUシステムはアルゼンチン以外で使用されていますか?
いいえ、CBUはアルゼンチン特有のものです。各国独自のシステムがあります:ヨーロッパはIBAN、米国はルーティング番号と口座番号、オーストラリアはBSBコードなどです。国際送金の際は、通常、受取人のSWIFTコードとローカルの口座識別子が必要になります。アルゼンチンの場合、それはCBUになります。
参考文献と公式文書
アルゼンチンの銀行基準に関する信頼性の高い情報については:
-
アルゼンチン中央銀行(BCRA) - 金融システム規制 - 決済システム基準と銀行規制に関する公式BCRA文書
-
法律第25,345号 - 「税務逋脱防止と支払いの近代化」(2000年11月) - アルゼンチンの電子決済システムの枠組みを確立した法律
-
BCRA通達「A」シリーズ - 金融機関のCBU実装要件を定義する技術的回状
-
インターバンキングS.A. - アルゼンチンの銀行間電子決済ネットワークを運営し、CBUルーティングテーブルを維持する組織
これらの情報源は、このバリデータを実装するための技術仕様を提供し、アルゼンチンの金融当局によって定期的に更新されています。
CBUの検証または生成の準備はできましたか?
支払い統合を構築している場合、フィンテックアプリケーションをテストしている場合、またはアルゼンチンの銀行システムについて学んでいる場合、CBUの検証を理解することが重要です。このツールは、アルゼンチンの銀行が使用するのと同じチェックサムアルゴリズムを実装しているため、トランザクションの失敗を引き起こす前に形式エラーを検出できます。
覚えておいてください:形式の検証は最初のステップにすぎません。適切な形式のCBUがあっても、アカウントが存在することや正しい受取人であることは保証されません。実際の資金を扱う本番システムの場合は、形式の検証を銀行APIや決済プロセッサを通じた追加の検証と組み合わせてください。
このツールは登録や設置を必要とせず、開いてすぐにBCRAの公式基準に従ってCBUを検証または生成できます。