JP2005539316A - 電子銀行取引システム - Google Patents

電子銀行取引システム Download PDF

Info

Publication number
JP2005539316A
JP2005539316A JP2004536629A JP2004536629A JP2005539316A JP 2005539316 A JP2005539316 A JP 2005539316A JP 2004536629 A JP2004536629 A JP 2004536629A JP 2004536629 A JP2004536629 A JP 2004536629A JP 2005539316 A JP2005539316 A JP 2005539316A
Authority
JP
Japan
Prior art keywords
bank
transaction
customer
financial transaction
document
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2004536629A
Other languages
English (en)
Inventor
アル‐アリ，アブドゥラハディ，エム．
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Saudi Arabian Oil Co
Original Assignee
Saudi Arabian Oil Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Saudi Arabian Oil Co filed Critical Saudi Arabian Oil Co
Publication of JP2005539316A publication Critical patent/JP2005539316A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/108—Remote banking, e.g. home banking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

金融取引を開始して自動的に処理する自動化された電子銀行取引システムは、取引記録を保持し、遠隔に位置する銀行の顧客に自動化された処理に対して金融取引要求に開始を許可する開始手段（１２）と、自動的に金融取引要求を受信して処理するのに適合する銀行ホストサーバ（２０）と、開始手段（１２）から銀行ホストサーバ（２０）に支払取引要求の伝送するために、銀行ホストサーバ（２０）と開始手段（１２）のデータ通信におけるコンピュータネットワーク（１６）と、開始手段（１２）とコンピュータネットワーク（１６）の間に位置し、自動的に銀行ホストサーバ（２０）へ開始手段（１２）をインターフェース接続し、かつ、銀行ホストサーバ（２０）と互換性のある読み取り可能な形式に金融取引要求を変換するインターフェース手段（１４）とを有する。

Description

本発明は、銀行取引に係り、詳しくは、銀行取引を円滑に処理するための電子銀行取引システムに関する。
顧客が金融機関に対して、銀行取引の登録（依頼）や資金振替、支払処理の明細書や報告書の請求などの取引注文を行う従来のシステムは、人の手によるマニュアル方式であるため時間が掛かり、非能率的で処理ミスや時間ロスを起こしやすい。
大抵の場合、人が介入するとともに、紙ベースの書類の受け渡しを基本とする処理であるので、処理速度の低下、過度な遅延の主な原因となっている。
このため、銀行取引を行う当事者は、個々の取引が完了するまで、かなり多くの時間を待たなければならず、例えば、多くの支部（支店）を経営し、毎日国際的な取引を行う大企業では、従来のシステムは非能率が顕著に現れることになる。
ベンダー（製品を販売する会社、若しくは製品のメーカーや販売代理店）と多くの顧客との間における支払取引の代表的な例としては、ベンダーは顧客に送付する請求書を用意して郵送する。請求書を受け取った顧客は、ベンダーとの取引を行った企業内の部署の取引状況と該請求書との照合処理を進める。つまり、各部署が請求書の支払いに対するチェック及び承認を行う。承認された請求は、その後買掛金としての処理が進められ、小切手が用意される。
このような従来のシステムは紙ベースでの処理であるため、内部的な書類（郵便）などのやり取りに極めて依存しており、支払いを完了させるのに約４週間の時間を要することがある。また、小切手は適切な管理者（管理職）による確認処理及び署名が行われてから、ベンダーに該小切手が送付される。
そして、小切手を受け取ったベンダーは、その後支払のために銀行へ小切手を提示し、取引の最後の部分はさらに処理するのに時間を要し（１時間から３日）、人の手を介した処理が要求され、小売銀行業務の取引が完了する。
顧客は銀行の取引明細書を定期的に又はインターネット等の電子手段を介してリアルタイムで受け取るが、非効率な小切手提示と洗い出しのため、前月の請求書に対する支払を照合させるのに２０〜３０日の時間を要求される。そして、もし、この支払処理の間に小切手を紛失した場合は、処理を繰り返し行うことになる。
それに鑑み、金融取引を顧客により自動的に処理することによって、銀行取引を自動的に処理する電子銀行取引システムが望まれており、銀行口座や受取人への電子的な支払や口座間の送金などを、遅延や人の介在を最小限に抑えつつ、現在の設備機器、ソフトウエア、通信構成を利用して行うシステムが望まれている。
さらには、多くの銀行との取引に関連する未払の金銭債務を正確、かつリアルタイムで評価（査定）することができ、計算の帳尻を合わせるのに必要な時間を短い時間で行うことができる電子銀行取引システムが望まれている。
そこで、本発明は、銀行と顧客との間で効果的かつ自動化されたインターフェースを提供するために使用可能な電子銀行取引システムに関連し、顧客が都合のよい場所から電子的に銀行取引依頼をシステムの多数のメンバーバンクに発行し、要求された金融取引の自動処理を開始することが可能なシステムを提供する。
また、既設の機器やソフトウエア、通信構成を使用して手軽に適用できる電子銀行取引システムを提供することにある。
さらには、グローバルネットワークを介して、独自の小売銀行業務の範囲で操作性に互換性のある電子銀行取引システムを提供することにある。
本発明の１つの観点としての電子銀行取引システムは、取引要求を受け取り、この取引要求を処理するのに適合する銀行ホストサーバと、自動操作で取引要求を開始させる開始手段と、銀行ホストサーバと開始手段との間のデータ通信であって、開始手段から銀行ホストサーバに取引要求を送信するグローバルコンピュータネットワークと、開始手段と銀行ホストサーバとを接続し、取引要求を銀行ホストサーバに互換性のある読み取り可能な形式に変換して、保護データ通信コネクションを確立するインターフェース手段（接続手段）とを有することを特徴とする。
本発明によれば、金融取引を顧客により自動的に処理し、銀行口座や受取人への電子的な支払や口座間の送金などを、遅延や人の介在を最小限に抑えた好適な電子銀行取引方法及び電子銀行取引システムを実現できる。
さらに、既存の設備機器、ソフトウエア、通信構成を利用することが可能であるため、コストを抑えて実現することができる。
本発明の１つの特徴的な実施例としては、インターネットのようなグローバルコンピュータネットワークやローカルネットワーク全体において人の介在や遅延を極力少なくし、適した金融口座に資金を送金する金融取引を含む自動化された電子金融システムであり、以下の実施例１から実施例３において詳細に説明する。
本発明は、電子銀行取引システムと銀行取引処理方法を指し示すものであり、第１の動作モード（支払モード）において、本発明の電子銀行取引システムは自動銀行取引処理に適しており、最小の人手、つまり人の手を極力介さずに、かつ迅速な方法で支払処理等における金融口座への資金送金を明瞭に行う。
さらに、本発明の電子銀行取引システムは、インターネットのようなグローバルコンピュータネットワークを利用でき、例えば既設のハードウエア構成及びソフトウエア構成に適用することができ、銀行、支払処理センター、手形交換所などを含む金融データ処理事業体（団体）と共同（連携）して容易に実施することが可能である。
また、本発明の特徴である金融取引処理の自動化は、多数の支部を持ち、国際金融取引を行う大きな組織（企業）のようなユーザに、銀行取引システムを用いた取引を同期的形態に行うことを提供する。このため、処理時間が短縮され、最小の人手で、かつ迅速なリアルタイム方式で、支払システムを銀行取引システムの口座記録と自動的に帳尻を一致させる照合などの調和を行うことが可能となる。
本電子銀行取引システムの主要なエンドユーザーは、財務管理を扱う人であって、システムにアクセスし、現行の処理に優先させて、取引の承認を引き受けることができるユーザである。
この財務管理人は、一般に大きな組織のグループの一部であり、保険、クレジット、外為借金、借金、投資、歳入に関連するリスク管理、債務管理、資産管理及び組織の国際的な商売に対して責任がある。
それゆえ、本発明の電子銀行取引システムはユーザとって統一され、かつ自動化された方法あって、企業組織の日々の金融的な操作の持続及び管理の機能を付与する使い勝手のよいツールを提供する。
本発明の１つの実施の形態である電子銀行取引システムは、金融取引の発生及び取引を開始する中央トランザクション処理部、インターネットを介して銀行との通信を行う中央インターフェース部及び、銀行インターフェース部の３つの主要構成部が設けられている。
これら３つの主要部は、取引の信頼性の証明及び、認証、取引を行い、現行のシステムに対しての確認などの処理の間、中央インターフェース部と通信リンクを形づくるために協力する。
ここで、本実施例は、以下の機能を提供することができる。
１）第三機関（第三者）への電子資金振替。
２）同じ銀行内での共通の口座間の電子資金振替。
３）異なる銀行での共通の口座間の電子資金振替。
４）一般の支払い。
５）一日の終わりに電子銀行明細の自動読み出し（検索）と自動調整。
６）第三機関へのファックス支払通知の生成。
７）受取人の銀行への満期日前支払いのファックス通知の生成。
８）本発明のシステムに対するバックアップを提供する自動電話機能。
９）顧客の金融債務を示す現金の状況報告の作成。
１０）本発明のシステムを通して統一された幾つかの加盟銀行に対して直接に口座の取引残高（会計バランス）をオンライン検索。
次に本実施例の電子銀行取引システムについて説明する。図１は電子銀行取引システムを適用した支払処理２２０を示す概略図である。
支払処理２２０は、ステップ２２２で開始され、このステップ２２２において、受取人若しくは支払先は、支払を受けるために請求書を用意し、個人、会社、大企業などの顧客２３０に提出する。
顧客２３０は購買課や会計課を含む十分大きな事業体であると仮定し、ステップ２２４では、請求書は、この請求書を再調査（検証）するため、若しくはさらなる会計処理や承認のために適切な顧客（購買人）の受取部署に送出される。そして、受取部署では請求情報を企業業務ソフトウエア又はワークフローソフトウエアシステム（企業における業務プロセスで、回覧・承認処理のために、申請書の滞留や回覧の遅延・記入漏れによる差し戻しなど、引継ぎやプロセスそのものに発生する無駄を省くためのシステム）に入力され、これらのソフトウエアシステムは、請求情報を適切な関係者に処理のために送信する。その後、電子ワークフロー承認プロセスを使用して、支払処理のために請求書の検証、電子的保存及び承認が行われ、支払処理を開始する発生部と買掛部との間で調整される。
ステップ２２６では、再検証及び承認のために請求書が発生部に送られ、ステップ２２８では請求承認が買掛処理に転送され、電子的な支払指示の形式で電子支払が用意される。このステップ２２４からステップ２２８までの工程は、一般的なワークフロー承認処理を介して顧客２３０の組織内部で実行される。
ステップ２３２では、顧客がコンピュータネットワークを介して銀行に電子支払指示を送出し、銀行は情報の処理を進め、顧客２３０により要求された支払処理を行う。また、ステップ２３４では支払指示が銀行２３２に送信されると同時に、銀行に送出された銀行取引要求の確認のために、ファクシミリ通知を受益人に送出する。なお、銀行取引は顧客の口座から受益者の銀行口座に電子的に送金したり、受益人に小切手を送信するなどの幾つかの方法で行われる。
図１Ｂは、本実施例に係る電子銀行取引システムを示す概略構成図であり、１０は本実施例の電子銀行取引システムである。
この電子銀行取引システム１０は、顧客側に設けられた銀行取引システムによって操作されるコンピュータサーバの中央トランザクション処理部１２と、この中央トランザクション処理部１２と接続され、中央トランザクション処理部１２が設けられている同じコンピュータ、若しくはインターネットのようなグローバルコンピュータネットワーク１６や異なるコンピュータサーバによって特定のアプリケーションでサポートされる中央インターフェース部１４と、顧客が取引を行う銀行が操作する銀行サーバ２０によってサポートされる銀行インターフェース部１８が順に接続されている。
この銀行インターフェース１８は、グローバルコンピュータネットワーク１６を介して顧客側の中央インターフェース部１４と通信し、また、付加的に電子銀行取引システム１０には、顧客との通信のためにさらにグローバルネットワーク１６に接続される受益者サーバ２２を含むことができる。そして、この中央トランザクション処理部１２と中央インターフェース部１４は顧客の設備（機器）に組み込まれてインストールされる。
中央トランザクション処理部１２は、顧客がアクセス可能なイントラネットワークの一部を構成しており、ペーパーレス環境でのサポート及び共通操作促進のために組織で使用される幾つかの標準的なビジネスソフトウエアから選択された企業内ソフトウエアにプログラムされている。なお、このようなビジネスソフトウエアは、ドイツのＳＡＰ社製の「ＳＡＰ Ｒ／３ＥＮＴＥＲＰＲＩＳＥ ＥＲＰ」（登録商標）などで構成される。
また、本実施例の電子銀行取引システムは、ＳＡＰソフトウエアやアプリケーションモジュールにプログラムされた形式で示されるが、これに限るものではなく、従来知られている他のソフトウエアにも適用可能である。
まず、現金管理取引はユーザや顧客の指定された役員による検証及び承認が行われると、中央トランザクション処理部１２が自動的に電子取引要求と支払命令を生成するようにプログラムされおり、さらなる人手を介すことなく取引が自動的に処理される。
生成された取引要求は、中央トランザクション処理部１２からデータ通信リンク２４を介して中央インターフェース部１４に転送され、中央インターフェース部１４では適合する銀行サーバ２０に、グローバルコンピュータネットワーク１６へのデータ通信リンク２６を介して送信するための取引要求を準備する。また、この中央インターフェース部１４は、中央トランザクション処理部１２と相当する銀行側の銀行サーバ２０とのグローバルネットワーク１６を経由した通信を手助けする。
この取引要求は、グローバルコンピュータネットワーク１６を使用して伝送され、銀行インターフェース部１８によって受信される。例えば、この銀行インターフェース部１８は、銀行サーバ２０に設けられたコンピュータサーバの一部若しくは専用のコンピュータであり、取引の信頼性の証明、認証及び取引を行ったり、取引要求を含む取引の確認をしたりするようにプログラムされている。
銀行インターフェース部１８は、銀行サーバ２０の特定の小売銀行業務を操作するために設定され、この銀行インターフェース部１８は、銀行サーバ２０の小売銀行業務に特定の形式にフォーマットされた取引要求を準備する。そして、銀行サーバ２０が取引要求を受信すると、該取引要求を含む命令が実行される。
図２は、本実施例に係る電子銀行取引システムの詳細説明図である。電子銀行取引システム１０は、イントラネット区域１３、インターフェース区域１５、ファイアウォール区域１７、グローバルコンピュータネットワーク区域（インターネット区域）１９が含まれている。
イントラネット区域１３には、統一カスタマイズ中央ソフトウエアシステム「ＳＡＰ Ｒ／３」（登録商標）のようなＳＡＰシステムの財務会計モジュール（ＳＡＰ ＦＩ）の一部であるＳＡＰ財務管理モジュール（ＳＡＰ−ＴＲ）などのアプリケーションモジュールをサポートするためにプログラムされた企業内ソフトウエアシステムが搭載された専用のローカルサーバ２１が設けられている。そして、本実施例では、他の機能とともにローカルサーバ２１が中央トランザクション処理部１２を動作させる。
ローカルサーバ２１は、権限のある顧客の指定された役員のようなユーザにアクセス権限を与えるために通信リンク２３を介して少なくとも１つのワークステーション若しくはクライアントコンピュータとの通信を行う。クライアントコンピュータ又は顧客のコンピュータは、「ＳＡＰ−ＧＵＩソフトウエアバージョン４．６Ｄ」のようなＧＵＩソフトウエアによって支援されている。
イントラネット区域１３はさらに、ローカルサーバ２１により処理されるデータを格納し、検索（読み込み）するために設けられたローカルサーバ２１に接続可能な中央トランザクションＤＢ（中央トランザクションデータベース記憶装置）３４が設けられている。この中央トランザクションＤＢ３４には、「オラクル５．７．３」のような適合するデータベースソフトウエアが搭載されている。
インターフェース区域１５には中央インターフェース部１４が設けられたインターフェースサーバ２５が設けられ、このインターフェースサーバ２５はローカルサーバ２１及びインターフェースサーバ２５間に確立された通信リンク２４とファイアウォール３８とを介してローカルサーバ２１に接続される。
ファイアウォール３８はインターフェース区域１５から顧客のイントラネット区域１３を隔離するように機能する。このファイアウォール３８の主要な機能は、相当するシステムとユーザとによる権限あるアクセスをするために、インターフェース区域１５と各サーバへのデータトラフィックを確保することである。
インターフェースサーバ２５は、グローバルコンピュータネットワーク、つまり本実施例では中央トランザクション処理部１２と銀行サーバ２０との間のインターネットを使用して通信を実施するためのオープンインターフェースソフトウエアがプログラムされている。なお、このオープンインターフェースは、後述するフローチャートに描かれるような、「ＳＡＰ Ｂｕｓｉｎｅｓｓ Ｃｏｎｎｅｃｔｏｒ」によって提供される。この「ＳＡＰ Ｂｕｓｉｎｅｓｓ Ｃｏｎｎｅｃｔｏｒ」 が動作するインターフェースサーバ２５は、ＲＦＣ（Ｒｅｍｏｔｅ Ｆｕｎｃｔｉｏｎ Ｃａｌｌｓ）経由して「ＳＡＰ Ｒ／３」が動作するローカルサーバ２１との通信を行う。
そして、インターフェースサーバ２５は、ローカルサーバ２１の中央トランザクション処理部１２からの全てのＲＦＣ形式の通信データを拡張可能なマーク付け言語（ＸＭＬ）に変換する。なお、グローバルコンピュータネットワーク１６を経由した通信は、ハイパーテキスト通信プロトコル形式（ＨＴＴＰ／ＨＴＴＰＳ）が使用される。
また、インターフェース区域１５は一対の個々のファイアウォール４０、４２が設けられたファイアウォール区域１７を介して、グローバルコンピュータネットワーク１６から切り離すように維持している。インターフェースサーバ２５からの送信されたデータは、グローバルコンピュータネットワーク１６を経由し、通信リンク２８を介して銀行サーバ２０に伝送される。
中央インターフェース部１４は、インターフェースサーバ２５に接続される中央インターフェースＤＢ（中央インターフェースデータベース記憶装置）３６をさらに備え、この中央インターフェースＤＢ３６は、中央トランザクションＤＢ３４と同様に構成され、中央インターフェース部１４に関連する全ての動作（に関する情報）を格納及び検索（読み込み可能な）手段が備えられている。なお、中央インターフェースＤＢ３６は、図２に示すように、イントラネット区域１３と同じ側でファイアウォール３８の後ろ側に設置されていることが望ましい。
ここで、図３Ａから図３Ｆを用いて本実施例における電子銀行取引システムの処理動作を詳細に説明する。本実施例では、中央トランザクション処理部１２が顧客の銀行口座の現金管理や支払などの金融取引を顧客が取引する銀行や複数の銀行に指示するために、適合する銀行サーバ２０への金融取引要求（取引命令）を生成する。各々の金融取引要求は、「ＳＡＰ Ｒ／３ ＦＩ−ＴＲ」モジュールによって生成され、この実施例では中央トランザクション処理部１２で生成される。
また、この取引要求は中間ドキュメント（ＩＤＯＣ）の形式で用意される。中間ドキュメントはインターフェースサーバ２５に転送され、ＸＭＬドキュメント形式に変換される。そして、顧客の銀行の予め指定された銀行サーバ２０に送信される。その後、予め指定された銀行サーバ２０は、ＸＭＬドキュメントを受信し、銀行インターフェース部１８は受信したＸＭＬドキュメントを銀行サーバ２０で処理するのに適合するドキュメント形式に再フォーマットする。
図３Ａは、本発明の原理に応じた本実施例における電子銀行取引システム１０の支払モード時を説明するためのフローチャート図である。
支払処理を開始するにあたって、中央トランザクション処理部１２は、支払プログラム（ＳＡＰアプリケーションにおけるトランザクションＦ１１０、Ｆ１１１）を実行して支払処理を行うために、ベンダーの請求処理や従業員の給料支払処理などの金融取引を自動的に選択する。
電子銀行取引システム１０のアルゴリズムはステップ５０から開始され、支払申込や支払プログラムによる取引要求を用意するためのパラメータを中央トランザクションＤＢ３４から読み出す（検索する）。この支払申込のパラメータは、例えば、登録日（支払の承認が行われた支払可能日）、次に支払が行われる日（支払期日を参照するために使われる次回支払実行日の登録データ）、会社コード（会社コード、若しくは、一緒に処理されるべき会社コード）、支払方法（小切手、為替手形、海外銀行送金）、ベンダー又は／及び顧客口座（考慮されるベンダー／顧客口座の範囲）である。
そして、ステップ５２では、中央トランザクション処理部１２は取引申込を生成し、送信した支払を含み、これから処理しようとする取引要求の全ての参照をユーザに許可する。これは、実際に支払取引の登録が行われる前に、ユーザがコンピュータ３２を介して初期照合を実施することを許可するためである。
そして、アルゴリズムはステップ５４に進み、中央トランザクション処理部１２によって支払プログラムが実行され、発行に備えて支払ドキュメント又は支払命令が生成される。
ステップ５６では、アルゴリズムは、各処理に相当する支払方法に基づく配置及び選択パラメータを含んでいる支払ドキュメント及び支払命令の適切な形式を判別する。上記支払方法とは、米ドルでの小切手支払処理のためのプログラム「ＺＦＲ００４４０」や電子送金支払処理のためのプログラム「ＲＦＦ０ＥＤｌ１」などの「ＳＡＰ Ｒ／３」のプログラムを使用した支払方法である。
その後、支払ドキュメントは、ステップ５８において中間ドキュメント（ＩＤＯＣ）形式で生成され、中央インターフェース部１４に送出される。１つの例として、例えば、電子送金支払処理に対して支払プログラムは、ＰＡＹＥＸＴドキュメント（ＰＡＹＥＸＴ＿ＩＤＯＣ）とＥＵＰＥＸＲ（ＥＵＰＥＸＲ＿ＩＤＯＣ）の２つの形式の中間ドキュメントを生成する。
ＰＡＹＥＸＴ＿ＩＤＯＣは、銀行を通じた１人の受取人の支払情報を含んでおり、ＥＵＰＥＸＲ＿ＩＤＯＣは、各々の銀行に対して生成された照会用中間ドキュメント（照会用ＩＤＯＣ）であり、この照会用中間ドキュメントは、ＰＡＹＥＸＴ＿ＩＤＯＣ番号のリストに一致するホスト銀行に送信された支払命令の要約情報の全てを有している。
例えば、「ＳＡＰ Ｒ／３」では、複数の中間ドキュメントはＲＦＣの目的ポートを介して中央インターフェース部１４に送出される。そして、中央トランザクション処理部１２は、ステップ６０において中間ドキュメントが送信されるとすぐに２つの形式の中間ドキュメントのステータスを「０３」に更新するとともに、データが正確にポートを通過したことを指し示すメッセージ「Ｄａｔａ ＰＡＳＳＥＤ ＴＯ ＰＯＲＴ ＯＫ」を出力する。
中央インターフェース部１４で受信した中間ドキュメントは、ＲＦＣキュー（ＲＦＣのデータ構造）内に配置されて格納される（ステップ６２）。また、ＥＵＰＥＸＲ＿ＩＤＯＣが受信されると、ＰＡＹＥＸＴ＿ＩＤＯＣ番号に準じた要約情報がＴ＿ＢＣ＿ＰＡＹＭＥＮＴ＿ＲＥＦＥＲＥＮＣＥテーブルとＴ＿ＢＣ＿ＰＡＹＭＥＮＴ＿ＲＥＦＥＲＥＮＣＥ＿ＤＥＴＡＩＬテーブルのそれぞれにマッピング及び格納される。
ステップ６４では、アルゴリズムは中央インターフェース部１４への通信リンク２４がアクティブか否かをチェックする。中央インターフェース部１４のインターフェースサーバ２５がダウン若しくは非アクティブであるときは、再び中間ドキュメントをアップするまで、「ＳＡＰ Ｒ／３」は全ての中間ドキュメントをＲＦＣ構造の待ち行列に入れる。
このキュー（待ち行列）は、送信が成功するか若しくはリトライ番号が９９９になるまでの間常に、ＲＦＣポートに保留された中間ドキュメントが送出されるように構成（設定）される。このリトライ番号は通信が行われる度に１ずつ値が増加される。
そして、ステップ６８においてアルゴリズムは、リトライ番号が９９９よりも大きいか否かの問い合わせを行い、リトライ番号が９９９よりも小さい場合は、ステップ７０に進み、中間ドキュメントはＲＦＣキューに再提出される。リトライ番号が９９９よりも大きい場合は、アルゴリズムはステップ７２に進み、ＳＡＰ監視者に接続障害の通知がされ、障害修復の開始を許可する。その後、ステップ７４では、ＳＡＰ監視者が接続障害を解決し、中間ドキュメントの再提出ためにステップ７０に進む。
ＳＡＰ監視者は、一般的に顧客の従業員で構成され、顧客のシステム、サーバ、構成及びハードウエアとソフトウエアの両面を含む本発明のシステムを形成している部分を監視する権限を与えられる。
監視者は、アプリケーションの動作間に生じるかもしれない幾つかの不正の修正又は障害復旧のために実施するに適した行為、つまり、障害復旧のためのプログラム修正や設備機器のチェックを行うための準備をする。
ステップ６４において、接続状態がアクティブと判別されたならば、アルゴリズムは図３Ｂに示すステップ７６に進む。図３Ｂのステップ７６において、中央インターフェース部１４は、支払情報を有するＰＡＹＥＸＴ＿ＩＤＯＣを受け取り、中間ドキュメントのパラメータフィールドを可変に割り当てるためにマッピングする。
ステップ７８において、インターフェースサーバ２５の中央インターフェース部１４は、中間ドキュメントを、データベーステーブル形式である銀行取引（ｅＢａｎｋｉｎｇ）データベースとしての中央インターフェースデータＤＢ３６のＴ＿ＢＣ＿ＰＡＹＭＥＮＴ＿ＴＲＡＮＳＡＣＴＩＯＮテーブルに格納するようにプログラムされている。
次に、ステップ８０においてインターフェースサーバ２５の中央インターフェース部１４は、ローカルサーバ２１の中央トランザクション処理部１２の中間ドキュメントのステータスを「０６」に更新するとともに、中央インターフェース部１４（インターフェースサーバ２５）に「ＳＡＰ ＲＦＣ」を使用してメッセージ「Ｔｒａｎｓａｃｔｉｏｎ ＯＫ」を出力する。
ステップ８２では、中央インターフェース部１４は、中間ドキュメントをＭＴ１００命令（顧客振替）にフォーマットする。このＭＴ１００命令は、国際銀行間データ通信システムによって実施される標準的なフォーマット規格に従っている。生成されたＭＴ１００命令は、ステップ８４においてＸＭＬ形式の取引ドキュメントにコンパイルされる。
これらの動作は全ての中間ドキュメントの番号をＥＵＰＥＸＲ＿ＩＤＯＣのような中間ドキュメントを通じて受信した情報とマッチングするために、Ｔ＿ＢＣ＿ＰＡＹＭＥＮＴ＿ＴＲＡＳＡＣＴＩＯＮテーブルから全ての支払命令を検索することで成し遂げられる。この処理は、その後に続く取引やホスト銀行サーバ２０に一致するシングルドキュメントとして登録することに対し、ホスト銀行に応じた支払命令をコンパイルするために実行される。なお、取引ドキュメント毎の支払命令の最大番号は、ホストバンクに依存している。
また、固有の前処理のための特定の要求や各々の銀行に対する取引ドキュメントの送信は、ＥＢＡＮＫＩＮＧ.ＣＮＦ構造（設定）ファイルのような構造ファイルに格納される。また、取引ドキュメントは、ＳＷＩＦＴ（Ｓｏｃｉｅｔｙ ｆｏｒ Ｗｏｒｌｄｗｉｄｅ ｉｎｔｅｒｂａｎｋ Ｃｏｍｍｕｎｉｃａｔｉｏｎ;国際銀行間決済システム若しくは国際銀行間データ通信システム）におけるＭＴ１００形式にフォーマットされ、そして、ＸＭＬタグ相当のものが循環する取引キュメントは、ホスト銀行サーバ２０への送信が待機される。
ステップ８６では、銀行特定パラメータ若しくは要求がＥＢＡＮＫＩＮＧ.ＣＮＦ構造ファイルから読み出され、ステップ８８において、特定の市販の利用可能なハッシングアルゴリズムを使用する電子署名認証を用いて、銀行特定パラメータは全ての取引ドキュメントを準備するために使用される。
証明（認証）は、送付に先立って、安全目的のための電子著名や認証に使用される。 ホスト銀行サーバ２０は、データの信頼性を確認し、金融取引の間に未改ざんの取引キュメントを含む情報であることを裏付けるために電子署名認証を使用する。
このアルゴリズムは、ＥＢＡＮＫＩＮＧ.ＣＮＦ構造ファイルに含まれる銀行特定パラメータを使用してＸＭＬ取引ドキュメントに対して電子署名を作成する。
ステップ９０において中央インターフェース１４部は、特定のホスト銀行サーバ２０への安全接続を確立する。これはＳＳＬ接続のセッティングをすることで成し遂げられ、認証ルートの認証パスに沿った取引ドキュメントの電子署名認証は、セッションを開始するために使用される。
アルゴリズムは、ステップ９２において、成功した接続が確立されているか否かを判別する。接続が確立されていない場合は、ステップ９４に進む。そして、中央インターフェース部１４は中央インターフェースＤＢ３６の銀行特定パラメータとともに、取引ドキュメントを該データベースのＴ＿ＢＣ＿ＦＡＩＬＥＤ＿ＳＥＲＶＩＣＥテーブルに格納する。このテーブルは、中央インターフェース部１４のサービスを含む全ての失敗（障害、不具合）を記憶する。
ステップ９６では、アルゴリズムは取引ドキュメントの再送出を自動的に開始する。失敗したサービスのリトライ処理の間隔は、この実施例では、約３分毎に行われる。
そして、アルゴリズムは、ステップ９８の問い合わせ処理に進み、リトライ番号が３よりも大きいか否かを判別し、接続確立の連続的な失敗は電子メール通知として、適した修正行為を行うために技術サポート及び企業チームに送られる。
支払ステータスツールとしての取引コード「ＦＺ０６４２」を有する報告書は、中央トランザクション処理部１２によって発行された全ての支払命令のステータスを参照するために、企業内チーム若しくは財務管理者に対して用意される。
そのレポートに対する見解が提供され、ビジネスチームは相当する銀行に取引ドキュメントを登録するための不測の事態の方法としてトランザクション（取引）のリトライ若しくは、TELEX／ファックス回線を用いた自動生成を行うことができる。
銀行に支払命令を送る不測事態プランやバックアップオプションは、中央インターフェース部１４若しくはホスト銀行サーバ２０が支払命令を処理できない事態において使用されることが可能となる。
この不測事態プランにおいて、支払命令を含んでいる取引ドキュメントは、中央トランザクション処理部１２のユーザにとっての要約レポートを含む、適したTELEXフォーマット内に設定され、テストコードを生成する。この電話回線により自動的に銀行へ送信される。
ステップ９８の問い合わせにおいて「ＹＥＳ」の場合は、アルゴリズムはステップ１００に進み、ここで、中央トランザクション処理部１２の中間ドキュメントのステータスは「１３」に変更され、中央トランザクション処理部１２に「ＳＡＰ ＲＦＣ」を使用してメッセージ「Ｅｒｒｏｒ ｗｈｉｌｅ ｐｏｓｔｉｎｇ ｔｈｅ ｐａｙｍｅｎｔｓ」を出力する。
ステップ１０２では、電子メールメッセージが権限ある中央トランザクション処理部１２のユーザに送られ、従来の確立された電話回線接続を介して手動で取引ドキュメントが銀行に発行される。
ユーザはトランザクション「ＺＦ０６４２」を実行して中央トランザクション処理部１２から発行された支払命令のステータスを参照し、そして、ステータスコード「１３」を含む全ての支払に対する電話回線処理報告書を抽出する。
電話回線処理報告書はユーザに表示され、銀行により提供される機密フォーマットに基づいてテストコード演算される。なお、各々の銀行は異なる機密フォーマットを使用している。個別の報告書が各々の銀行に対して、失敗した全ての支払を指し示すように用意される。
ステップ１０４において権限のあるユーザは、ホスト銀行に電話回線処理を介して取引キュメントを発行し、アルゴリズムの動作が完了する。
そして支払取引が成功した後に、ユーザは支払が銀行に受け入れられたことを示すために、中間ドキュメントのステータスコードを「１２」に更新する。
一方、ステップ９８の問い合わせ処理において「ＮＯ」の場合は、アルゴリズムはステップ８８に進み、ホスト銀行サーバ２０との安全な接続の復旧を始める。ステップ９０において、ホスト銀行サーバ２０との安全な接続が確立されたならば、ステップ９２の問い合わせ処理は「ＹＥＳ」となり、アルゴリズムはステップ１０５に進む。ステップ１０５では、中央インターフェース部１４は、支払命令を含む取引キュメントを送信する。そして、ホスト銀行サーバ２０の銀行インターフェース部１８にグローバルコンピュータネットワーク１６を介して電子署名を行う。
そして、顧客の銀行２７は従来知られている小売銀行業務システムを使用して支払命令の処理を実行する。
図３Ｃにおいて、アルゴリズムはステップ１０６に進み、ここで、中央インターフェース部１４は、銀行サーバ２０の銀行インターフェース部１８からのＸＭＬ形式の応答ドキュメントを待ち受ける。このＸＭＬ形式のドキュメントは、銀行に登録された各々支払命令の応答ステータスコードとメッセージを含んでいる。
ステップ１０８では、中央インターフェース部１４は、銀行インターフェース部１８から応答ドキュメントを受信する。そして、銀行と顧客との間で通信された全てのＸＭＬドキュメントは本システムに記憶され、個々に「Ｄｏｃｕｍｅｎｔ Ｓｅｎｄ」、「Ｄｏｃｕｍｅｎｔ Ｒｅｃｅｉｖｅｄ」として概ね確認される。
ステップ１１０では、応答ドキュメントのリターンコード及びメッセージが、監視（監査）目的のために、Ｔ＿ＢＣ＿ＤＯＣＵＭＥＮＴ＿ＲＥＣＥＩＶＥＤテーブルのフォーマットで、中央インターフェースＤＢ３６に格納される。
そして、中央インターフェース部１４は、ステップ１１２において個々の支払命令に対する応答ドキュメントのステータスを処理する。アルゴリズムはステップ１１４に進み、ここで、各々の支払命令のステータスが中央インターフェース部１４で判別される。
ステップ１１４でリターンコードが「ＯＫ」と判別されたならば、アルゴリズムはステップ１１６に進み、このステップ１１６においてＭＴ１００形式の支払命令がホスト銀行による受け入れ成功か否かが判別される。
中央インターフェース部１４は、その後、中央トランザクション処理部１２の中間ドキュメントのステータスを「１２」に更新し、メッセージ「Ｐａｙｍｅｎｔ ｓｕｃｃｅｓｓｆｕｌｌｙ ａｃｋｎｏｗｌｅｄｇｅｄ ｂｙ ｔｈｅ ｂａｎｋ」を「ＳＡＰ ＲＦＣ」を中央インターフェース部１２に呼び出して出力する。
支払処理の成功が記載されている報告書は、後述するトランザクションＺＦ０６４２を使用して生成することができる。
一方、ステップ１１４の問い合わせにおいて、リターンコードが「ＤＥ」、「０１」、「０９」である場合には、アルゴリズムはステップ１２０に進み、ＭＴ１００形式の支払命令が無効であるか否かが判別される。支払命令はデータ検証エラーを含んでおり、このエラーは、間違ったマスタデータや中央トランザクション処理部１２によって入力されたプロフィール情報などのビジネスデータを含んでいる。
そして、アルゴリズムはステップ１２２に進み、中央インターフェース部１４は、銀行による検証のために支払受理の失敗信号を発しつつ、この中央インターフェース部１４における中間ドキュメントのステータスを「１１」に更新する。そして、アルゴリズムは図３Ｄに示すステップ１２４に進む。
ステップ１２４では、中央インターフェース部１４は銀行からの適合するエラーメッセージとともに中央トランザクション処理部１２のユーザに電子メール通知書を送信する。
そして、アルゴリズムはステップ１２６に進み、エラーによる拒否が有効であるか否かの問い合わせを行う。問い合わせが「ＮＯ」であれば、アルゴリズムはステップ１２８に進み、ここで、中央トランザクション処理部１２のユーザは、中間ドキュメントのステータスを「１３」に設定するための支払取消ツールとしてのトランザクションＺＦ０６４６と支払ステータスをレポートすることを実施するためのトランザクションＺＦ０６４２とを開始し、支払命令が電話回線を介して銀行に提示される。ステップ１３０では、確認書として銀行から電話回線で受領書を受け取り、システム１０の動作が完了する。
ステップ１２３において、拒否が有効と判断されたならばアルゴリズムはステップ１３２に進み、中央トランザクション処理部１２のユーザがトランザクションＺＦ０６４２を開始し、支払処理を取り消す。
ステップ１３４では、ユーザは、エラーが発生したデータに必要な修正を行い、ステップ１３６において修正された支払命令が中央トランザクション処理部１２に再記入され、ここで、アルゴリズムが図３Ａのステップ５０に戻る。
また、図３Ｃのステップ１１４における問い合わせにおいて、リターンコード「Ｆａｉｌｅｄ」と判別された場合、アルゴリズムはステップ１３８に進み、ホスト銀行サーバ２０でのサービス及びコンポーネントが失敗してしまったことについて判別する。
アルゴリズムはステップ１４０に進み、リターンコードは銀行側の技術的障害として取り扱い、中央インターフェース部１４が、技術的問題のために銀行による支払受け入れが失敗した信号を発することで、メッセージ「Ｅｒｒｏｒ while ｐｏｓｔｉｎｇ ｔｈｅ ｐａｙｍｅｎｔ ｉｎｓｔｒｕｃｔｉｏｎ」とともに、この中央インターフェース部１４における中間ドキュメントのステータスを「１３」に更新する。
そして、アルゴリズムは図３Ｅのステップ１４２に進み、技術的困難のために支払が拒否された理由とともに、中央トランザクション処理部１２のユーザに電子メール通知書を送信する。
その後、アルゴリズムは１４４に進み、中央トランザクション処理部１２のユーザが支払報告に対してトランザクションＺＦ０６４２を開始し、電話回線通信を介して銀行に支払命令を提示する。ステップ１４６では、確認書として銀行から電話受領書を受け取り、電子銀行取引システム１０の動作が完了する。
ここで、図３Ｃに戻って、アルゴリズムは、ステップ１１４の問い合わせでリターンコードが「ＤＵＤＥ」の場合はステップ１４８に、「ＤＵＯＫ」である場合はステップ１５０にそれぞれ進み、ここで、支払命令が複製（二重送信）されたか否かが判別される。
リターンコード「ＤＥＤＥ」は、ＤＥエラーで拒否された支払に対して銀行により返信されたコードであり、リターンコード「ＤＵＯＫ」は、前回の取引で受領された支払に対して銀行サーバ２０により返信されたコードである。
ステップ１４８、１５０の各々において、中央インターフェース部１４はリターンコードが「ＤＵＤＥ」、「ＤＵＯＫ」であるか否かを判別する。もし、リターンコードが「ＤＵＤＥ」の場合は、アルゴリズムはステップ１５４に進み、中央インターフェース部１４が中央トランザクション処理部１２における最新の支払命令の中間ドキュメントのステータスをチェックする。ステップ１５６の問い合わせで、中央インターフェース部１４はステータスコードが「１１」、若しくは銀行により支払が拒否されたか否かを判別する。
この問い合わせが「ＮＯ」であれば、アルゴリズムは図３Ｄのステップ１２４に進み、「ＹＥＳ」の場合は、アルゴリズムはステップ１５８に進む。このステップ１５８では中央インターフェース部１４は、なぜ支払命令が再び登録されてしまったのかの障害復旧のために、技術者に電子メール通知を送信する。そして、電子銀行取引システム１０の動作が完了する。
一方、ステップ１５２において、リターンコードが「ＤＵＯＫ」である場合、アルゴリズムはステップ１６０に進み、中央インターフェース部１４が中央トランザクション処理部１２における最新の支払命令の中間ドキュメントのステータスをチェックする。
ステップ１６２の問い合わせにおいて、中央インターフェース部１４はステータスコードが「１２」若しくは銀行によって認証された支払であるか否かを判別する。この判別において「ＮＯ」の場合は、アルゴリズムはステップ１６４に進み、中央インターフェース部１４がメッセージ「Ｐａｙｍｅｎｔ ｓｕｃｃｅｓｓｆｕｌｌｙ ａｃｋｎｏｗｌｅｄｇｅｄ ｂｙ ｂａｎｋ」とともに、この中央インターフェース部１４における中間ドキュメントのステータスコードを「１２」に更新し、電子銀行取引システム１０の動作が完了する。
また、ステップ１６２における問い合わせにおいて「ＹＥＳ」ならば、アルゴリズムはステップ１６６に進み、中央インターフェース部１４は支払命令が複製されたので、修正行為が取られるべきであるとして、中央トランザクション処理部１２のユーザと技術者に電子メール通知を送信する。そして、システム１０の動作が完了する。
なお、ホスト銀行サーバ２０へ伝達された支払命令は、エラーが発生しても銀行インターフェース部１８で自動的に修復されるべきではない点に留意する。全てのエラーを有する支払命令は、詳細なメッセージとリターンコードとともに中央インターフェース部１４に返信される。
中央インターフェース部１４は、トランザクションＺＦ０６４２を用いて全ての支払成功（ステータスコード「１２」）のために、支払通知書を生成するように設定されることができる。
図４は電子銀行取引システム１０の動作を詳細に説明するフローチャートであり、上記図３Ａから図３Ｆの支払モードと異なる照合モード時の制御ステップを示すものである。
銀行明細書は、通常、銀行の業務時間の後であって、自動調整に対する合意が行われた時間（次の日の朝早い時間など）に、一日に一度読み出される。銀行から受信したデータは、銀行明細書における個々の取引の種類に応じた情報を含んでいる。
例えば、取引コードは、手形支払取引、電子支払、銀行送金、若しくは顧客受領などを表すためのコードである。また、それぞれに関連する情報（小切手番号、整理番号など）は、銀行明細書に含まれる。銀行明細書を含む情報に基づいて、中央トランザクション処理部１２に格納された全ての未解決取引は、照合するときに自動的にクリアーすることができ、電子銀行明細書が受信されると、中央インターフェース部１４によって、中央トランザクション処理部１２で認証できるフォーマットに変換される。
ステップ１６８において、中央トランザクション処理部１２は中央インターフェース部１４に送られる明細要求を開始する。ステップ１７０において、中央インターフェース部１４は、明細要求を受信し、ＸＭＬドキュメントに変換する。
ステップ１７２では、中央インターフェース部１４はＥｂａｎｋｉｎｇ.ＣＮＧ構造形式のファイルから要求パラメータを読み出し、グローバルコンピュータネットワーク１６を通じたＳＳＬ接続を確立する。銀行インターフェース部１８を介した銀行サーバ２０への安全な接続は、ステップ１８０で確立される。
アルゴリズムはステップ１８２に進んで、通信接続が無事に確立されたか否かを判別する。この問い合わせ処理において「ＮＯ」の場合は、アルゴリズムはステップ１７４に進み、リトライ番号が３よりも大きいか否かを判別する。リトライ番号が３よりも小さい場合は、アルゴリズムはステップ１８０に戻り、リトライ番号が３よりも大きい場合は、ステップ１７６に進み、中央インターフェース部１４は、中央トランザクション処理部１２のユーザ及び技術者に接続障害を通知するために、電子メール通知を送信する。ステップ１７８では、中央インターフェース部１４は中央トランザクション処理部１２の例外として取り上げ、明細要求を手動で開始する。
ステップ１８２において無事にセッションが確立された場合は、アルゴリズムはステップ１８４に進み、ここで、ＸＭＬ形式の明細要求がインターフェースサーバ２５の中央インターフェース部１４によって、グローバルコンピュータネットワーク１６を介して、ホスト銀行サーバ２０に登録される。
ホスト銀行サーバ２０は、銀行明細を含む応答要求を、関連する銀行インターフェース部１８に送信し、ＭＴ９４０明細書がＸＭＬ形式に変換され、その後、ステップ１８６において、銀行インターフェース部１８がグローバルコンピュータネットワーク１６を介して、中央インターフェース部１４に伝送する。
ステップ１８８において、中央インターフェース部１４は、監査目的のために、明細要求及び要求応答のそれぞれを中央インターフェースＤＢ３６のＴ＿ＢＣ＿ＤＯＣＵＭＥＮＴ＿ＳＥＮＴテーブルと、Ｔ＿ＢＣ＿ＤＯＣＵＭＥＮＴ＿ＲＥＣＥＩＶＥＤテーブルに格納する。
ステップ１９０では、ＳＷＩＦＴ標準に応じたＭＴ９４０形式の銀行明細書は、要求応答から抽出され、中央トランザクション処理部１２に格納される。
ステップ１９２において、中央トランザクション処理部１２は、銀行明細を含むデータを取り込み、取引内容との帳尻を一致させる。そして、電子銀行取引システム１０のオペレーションが完了する。
図５は電子銀行取引システム１０の動作を詳細に説明するフローチャートであり、表示モード時の制御ステップを示すものである。
ホスト銀行サーバ２０から直接にリアルタイムで明細を参照するオンライン銀行明細書のアクセスは、コンピュータ３２を介してユーザに提供される。明細参照アクセスは、参照目的のために提供され、データの帳尻を一致させるような調和目的するためではない。
ステップ１９４において、ユーザの要求に応じて、中央トランザクション処理部１２は、オンライン銀行明細書参照のためのオンライン明細書レポートツールであるトランザクションＺＦ０６４０を通じて明細要求を開始する。
ステップ１９６では、中央インターフェース部１４は明細要求を受け取り、ＸＭＬ形式にフォーマットする。ステップ１９８では、中央インターフェース部１４は、銀行特定パラメータを読み出し、グローバルコンピュータネットワーク１６を介したホスト銀行サーバ２０とのＳＳＬ接続を確立する。
安全接続はステップ２００で行われ、ステップ２０２において中央インターフェース部１４が、安全接続が確立したか否かの判別を行う。「ＮＯ」ならば、アルゴリズムはステップ２０４に進み、トランザクションＺＦ０６４０機能に相当するリターンコネクションエラーメッセージを要求しているユーザに表示し、電子銀行取引システム１０の動作が完了する。
一方、ステップ２０２の判別において、「ＹＥＳ」ならば、アルゴリズムはステップ２０６に進み、明細要求パラメータを含む明細要求が銀行インターフェース部１８に登録される。
銀行インターフェース部１８は、ホスト銀行サーバ２０に明細要求をアップロードするための処理を行う。そして、ホスト銀行サーバ２０は、銀行インターフェース部１８にＳＷＦＩＴのＭＴ９４０形式明細書を生成する。
そして、銀行インターフェース部１８は、銀行明細書をＸＭＬ形式に変換し、中央インターフェース部１４に伝送する。ステップ２０８において、中央インターフェース部１４は銀行明細書を受信し、ステップ２１０において、中央インターフェース部１４は、銀行明細書からのＭＴ９４０形式データの出力処理を行う。そして、ユーザに表示するために中央トランザクション処理部１２にアップロードする。
以上、上述の本発明を詳細な各実施例において説明したが、本発明の実施の形態はこれに限定されることなく、従来の幾つかの技術により、これらの実施例に対して請求項に記載の技術の適用を受けることができるように変更してもよい。
例えば、インターネットなどのグローバルコンピュータネットワーク１６は、データ接続パスや顧客側のローカルサーバ２１と銀行側のサーバ２０との間のリンクを提供するように説明しているが、グローバルコンピュータネットワーク１６は、顧客とそれぞれの銀行が位置する大きな建物内で通信を行うローカルエリアネットワーク（ＬＡＮ）若しくは、同じビジネス街（ビジネス地区）に顧客とそれぞれの銀行が位置して通信を行うワイドエリアネットワーク（ＷＡＮ）であってもよい。
本発明の実施例１における電子銀行取引システムを適用した支払処理を示す概略図である。 本発明の実施例１における電子銀行取引システムの概略図である。 本発明の実施例１における電子銀行取引システムの構成概略図である。 本発明の実施例１における電子銀行取引システムの詳細な制御ステップを示すフローチャート図であり、支払モード時の制御ステップである。 本発明の実施例１における電子銀行取引システムの詳細な制御ステップを示すフローチャート図であり、支払モード時の制御ステップである。 本発明の実施例１における電子銀行取引システムの詳細な制御ステップを示すフローチャート図であり、支払モード時の制御ステップである。 本発明の実施例１における電子銀行取引システムの詳細な制御ステップを示すフローチャート図であり、支払モード時の制御ステップである。 本発明の実施例１における電子銀行取引システムの詳細な制御ステップを示すフローチャート図であり、支払モード時の制御ステップである。 本発明の実施例１における電子銀行取引システムの詳細な制御ステップを示すフローチャート図であり、支払モード時の制御ステップである。 本発明の実施例２における電子銀行取引システムの詳細な制御ステップを示すフローチャート図であり、照合モード時の制御ステップである。 本発明の実施例３における電子銀行取引システムの詳細な制御ステップを示すフローチャート図であり、表示モード時の制御ステップである。
符号の説明
１２ 中央トランザクション処理部
１４ 中央インターフェース部
１６ インターネット（グローバルコンピュータネットワーク）
１８ 銀行インターフェース部
２０ 銀行サーバ
２１ ローカルサーバ
２２ 受益者サーバ
２５ インターフェースサーバ

Claims (27)

  1. 銀行の顧客に間接的に権限を与え、かつ前記銀行で行われる電子金融取引の要求を許可する自動化された電子銀行取引方法であって、
    顧客側でコンピュータ化されたシステムを提供するステップと、
    前記顧客の銀行に対して金融取引を指示するために、前記顧客側システムからの要求、若しくは顧客が手動で入力した要求を受信するステップと、
    中間ドキュメントとして適切にフォーマットされた金融取引ドキュメントを生成するために前記要求に応じて、前記顧客側システムで金融取引プログラムを実行するステップと、
    更なる処理のために、前記中間ドキュメントが顧客側システムに設けられたインターフェースサーバを通過することを許可し、前記顧客側システムにおいて自動的に前記中間ドキュメントを所定期間、待ち行列に保持するステップと、
    前記インターフェースサーバが自動的に前記中間ドキュメントをＸＭＬ形式のドキュメントに変換するプログラミングステップと、
    コンピュータネットワークを使用して、ＸＭＬ形式の前記中間ドキュメントを前記顧客側システムから前記顧客の銀行における互換性を有する銀行サーバに自動送信するステップと、
    前記中間ドキュメントに応じて、前記銀行サーバを経由して要求された金融取引を自動処理するステップとを有することを特徴とする電子銀行取引方法。
  2. ＸＭＬ形式のステータスドキュメントを前記顧客に送信するために前記銀行サーバを自動的に操作するステップと、
    顧客側システムで前記ステータスドキュメントを受信するステップと、
    前記顧客が受信した前記ステータスドキュメントを読み取るために前記顧客側システムを許可する動作ステップと、
    受信した前記ステータスドキュメントを前記顧客側システムに設けられた中央トランザクションデータベース記憶装置に自動的に記憶するステップとを有することを特徴とする請求項１に記載の電子銀行取引方法。
  3. 前記金融取引プログラムを実行するステップは、
    要求された金融取引に対してパラメータを入力するステップと、
    金融取引申込を作成するステップと、
    前記中間ドキュメントを生成するために金融取引実行を遂行するステップとを有することを特徴とする請求項１に記載の電子銀行取引方法。
  4. 前記ＲＦＣ待ち行列に保持するステップは、
    前記中間ドキュメントを前記銀行サーバの送信先に発行するステップと、
    前記中間ドキュメントのステータスを、ポート通過成功データを表すデジタル化されたコードに更新するステップと、
    前記ポートで受信され前記待ち行列内の前記中間ドキュメントを実行するステップと、
    前記銀行サーバとの通信リンクがアクティブ若しくは非アクティブかを判別するチェックステップとを有することを特徴とする請求項１に記載の電子銀行取引方法。
  5. 前記銀行サーバに設けられた銀行側インターフェースサーバとの通信が非アクティブ状態であることに応答して、リトライ番号のカウンタを１ずつ増加させるステップと、
    前記リトライ番号が所定の最大番号よりも大きいか否かを判別するステップと、
    前記リトライ番号が前記最大番号を超えていなければ、前記中間ドキュメントを前記待ち行列に再出力するステップと、
    前記チェックステップを繰り返し行うステップとを有することを特徴とする請求項４に記載の電子銀行取引方法。
  6. 前記リトライ番号が前記所定の最大番号よりも大きいことに応答して、前記銀行側インターフェースサーバとで確立している通信のリンケージ障害を復旧する作業者に通知するステップと、
    前記リンケージ障害が解決された通信に応答して、前記待ち行列に前記中間ドキュメントを再出力するステップと、
    前記チェックステップを繰り返し行うステップとを有することを特徴とする請求項５に記載の電子銀行取引方法。
  7. 前記銀行側インターフェースサーバがアクティブであることに応答して、前記中間ドキュメントのパラメータフィールドを可変に割り当てるためにマッピングするステップと、
    前記中間ドキュメントデータを銀行取引データベースに格納するステップと、
    前記中間ドキュメントのステータスを取引が受理されたことを表すように更新するステップと、
    前記中間ドキュメントを国際銀行間データ通信システムによって実施されている標準フォーマットに従った命令にフォーマットするステップと、
    前記フォーマットされた中間ドキュメントと、それに続くフォーマットされた中間ドキュメントのそれぞれをＸＭＬ形式の取引ドキュメントにコンパイルするステップと、
    前記銀行サーバに設けられたＣＮＦ構造ファイルから銀行特定パラメータを読み出すステップと、
    クライアント認証を使用して、各々のＸＭＬ形式ドキュメントに対する電子署名を作成するステップと、
    前記銀行サーバとの安全接続を確立するステップと、
    前記安全確立が成功したか否かを判別するステップと、
    前記安全接続の確立成功に応答し、前記コンピュータネットワークを使用して前記銀行サーバに、取引命令とデジタル署名を含む各トランザクションドキュメントを送信するステップとを有することを特徴とする請求項４に記載の電子銀行取引方法。
  8. 前記安全接続の確立失敗に応答して、前記銀行特定パラメータとともに前記ＸＭＬドキュメントを、失敗したサービスと名づけられたデータベースに記録するステップと、
    前記電子署名を作成するステップ、前記安全接続を確立するステップ及び前記安全接続が確立されたか否かを判別するステップの連続するステップを再試行するステップと、
    前記リトライ番号が所定の最大番号よりも大きいか否かを判別するステップと、
    前記リトライ番号が前記最大番号よりも小さい場合に自動的に再試行を継続するステップとを有することを特徴とする請求項７に記載の電子銀行取引方法。
  9. 前記リトライ番号が前記最大番号を超えたことに応答して、前記中間ドキュメントのステータスを、支払登録の間に生じたエラーを表すコードに更新するステップと、
    従来の確立された電話又はファックス回線伝送を介した支払発行のために、前記顧客の権限ある役員に電子メール通知を送信するステップと、
    前記電子メールに応答して、前記銀行に電話又はファックス回線を介して前記権限ある役員が金融取引ドキュメントを発行又は提供するステップと、
    前記中間ドキュメントのステータスを、前記銀行によって認証されて正常に終了した金融取引を表すコードに更新するステップとを有することを特徴とする請求項８に記載の電子銀行取引方法。
  10. 前記コンピュータネットワークを使用して銀行からの応答を待機するステップと、
    前記顧客の銀行に登録された各金融支払命令に対する応答ステータスコードとメッセージを含むＸＭＬ形式の応答ドキュメントを前記銀行から受信するステップと、
    前記応答ドキュメントを前記銀行取引データベースに格納するステップと、
    前記各金融取引命令に関連した前記応答ドキュメントのステータスを処理するステップと、
    銀行からの前記各金融取引の前記ステータスを判別するステップとを有することを特徴とする請求項７に記載の電子銀行取引方法。
  11. 前記銀行から前記各金融取引の前記ステータスを判別するステップは、
    前記銀行によって処理が成功した金融取引に対して、ＯＫに相当するステータスコードを表示するステップと、
    通知した金融取引が無事に行われた前記銀行を示すコードを有するように、関連した中間ドキュメントのステータスを更新するステップとを有することを特徴とする請求項１０に記載の電子銀行取引方法。
  12. 前記銀行で金融取引拒否をもたらしたデータエラーに相当するステータスコードを表示するステップと、
    前記金融取引における前記中間ドキュメントのステータスをデータエラーが原因での取引拒否であることを示すコードに更新するステップとを有することを特徴とする請求項１０に記載の電子銀行取引方法。
  13. 前記権限ある顧客の役員に、前記金融取引拒否の理由を示す電子メール通知を送信するステップと、
    前記金融取引拒否が有効であるか否かを権限ある役員の行為によって判別するステップと、
    前記金融取引拒否が有効であることに応答し、前記権限ある役員の行為により銀行取引トランザクションを使用して前記金融取引要求を破棄するステップと、
    前記権限ある役員の行為を介して、前記銀行に金融取引拒否をもたらしたデータを修正するステップと、
    処理を完了するために、前記顧客側システムを通じて修正された金融取引を再処理するステップとを有することを特徴とする請求項１２に記載の電子銀行取引方法。
  14. 無効な金融取引拒否に応答して、前記権限ある役員の行為により適合する銀行取引コードを使用し、テスト済みの電話回線伝送を介して前記銀行に前記金融取引を発行するステップと、
    前記金融取引の完了を確認する、前記銀行からの受領確認を前記顧客側システムを介して受信するステップとを有することを特徴とする請求項１３に記載の電子銀行取引方法。
  15. 不明な理由で前記金融取引の完了が失敗した前記銀行に対して、前記金融取引が失敗したことに相当するステータスコード表示するステップと、
    前記中間ドキュメントの失敗を表すコードに対応して、前記中間ドキュメントのステータスを前期金融取引が失敗したことを示すコードに更新するステップとを有することを特徴とする請求項１０に記載の電子銀行取引方法。
  16. 前記銀行での前記金融取引が完了するために前記金融取引が失敗した理由を前記銀行から前記権限ある役員に電子メール通知を介して送信するステップと、
    前記権限ある役員の行為により前記適した銀行取引コードを使用し、テスト済みの電話又はファックス回線を介して、前記銀行に前記金融取引を完了するための許可を発行するステップと、
    前記電話又はファックス回線を介し、前記銀行から前記金融取引が完了した確認書を前記顧客が受信するステップとを有することを特徴とする請求項１５に記載の電子銀行取引方法。
  17. 顧客側システムによる二重伝送に対して、データエラーのために前記銀行によって拒否された前の伝送に相当するＤＵＤＥコード、又は顧客側システムによる二重伝送に対して、前記銀行によって処理成功した前の伝送に相当するＤＵＯＫコードのどちらかの前記銀行からのリターンステータスコードを表示するステップと、
    前記顧客側システムを介して、前記リターンステータスコードが前記ＤＵＤＥコードか前記ＤＵＯＫコードかを判別するステップと、
    前記ＤＵＤＥステータスコードに応じて、金融取引のための最新の中間ドキュメントのステータスがデータエラーのために前記銀行によって拒否された取引であることを表すか否かを判別するステップと、
    前記データエラーのための拒否に応じて、前記金融取引が前記銀行に二重に登録された原因の障害復旧のために電子メール通知を技術者に送信するステップと、
    前記データエラーで拒否されていないことに応じて、前記銀行によって拒否された金融取引の原因を指し示すために、前記顧客の権限ある役員に電子メール通知を送信するステップとを有することを特徴とする請求項１０に記載の電子銀行取引方法。
  18. ＤＵＯＫのステータスコードに応じて、前記金融取引における最新の中間ドキュメントのステータスが前記銀行により取引の処理が成功したことを指し示しているか否かを判別するステップと、
    直前の前記判別するステップでのＮＯ回答に応じて、前記中間ドキュメントのステータスを処理が成功したことを指し示すコードに変更するステップと、
    前回の関連する判別ステップでのＹＥＳ回答に応じて、前記顧客側システムにおいて金融取引が二重であったことを指し示すために、前記顧客の権限ある役員と前記顧客の技術者に電子メール通知を送信するステップとを有することを特徴とする請求項１７に記載の電子銀行取引方法。
  19. スケジューラーを用いた前記顧客の行為により銀行明細書の要求を開始するステップと、
    前記要求をＸＭＬドキュメントに変換するために、前記顧客側の前記インターフェースサーバに前記要求を通すステップと、
    前記コンピュータネットワークを使用し、前記顧客側システムの構造ファイルからＳＳＬ接続を確立するのに必要な要求されたパラメータを読み出すステップと、
    前記コンピュータネットワークを使用して前記銀行サーバへの安全接続を確立するステップと、
    前記安全接続の確立が成功したか否かを判別するステップと、
    前記安全接続の確立の失敗に応じて、許容される最大番号よりもリトライ番号が大きいか否かを判別するステップと、
    前記リトライ番号が前記最大番号を越えたことに応答して、前記顧客の役員と技術者に接続又は前記明細書の読み込みが失敗してことについての通知書を電子メールで送信するステップと、
    前記明細書の手動での要求を許可するために失敗例外をスケジューラーに取り上げるステップとを有することを特徴とする請求項１に記載の電子銀行取引方法。
  20. 前記安全接続の確立ステップでの接続成功に応答して、明細要求パラメータを含むＸＭＬドキュメントを前記銀行サーバに登録するステップと、
    前記顧客側システムにおいて、前記銀行からのＸＭＬ形式の応答の中の明細書を読み込むステップと、
    前記顧客側の銀行取引データベースにＸＭＬ形式の要求及び応答の両方を格納するステップと、
    指定されたフォルダにファイルを作成するために、前記銀行取引データベースから前記明細書を読み出すステップと、
    標準化された銀行取引ビジネスソフトウエアの使用を通じて、前記明細書の帳尻を一致させるステップとを有することを特徴とする請求項１９に記載の電子銀行取引方法。
  21. 銀行取引コードを使用した前記顧客の行為により、完了した金融取引を表示する明細書の要求を開始するステップと、
    前記インターフェースサーバを介して前記要求をＸＭＬ形式のドキュメントに変換するステップと、
    コンピュータネットワークを使用して前記銀行サーバへの安全な接続を確立するために必要な要求されたパラメータを前記顧客側システムにおける構造ファイルから読み込むステップと、
    前記コンピュータネットワークを使用して、前記銀行サーバへの安全接続を確立するステップと、
    前記安全接続の確立が成功したか否かを判別するステップと、
    前記安全接続の確立が失敗したことに応答して、前記顧客に表示するための接続エラーメッセージを返信するステップとを有することを特徴とする請求項１に記載の電子銀行取引方法。
  22. 前記安全接続の確立が成功したことに応答して、前記明細要求パラメータを含むＸＭＬドキュメントを前記銀行サーバに登録するステップと、
    前記銀行からのＸＭＬ形式にフォーマットされた明細書についての応答を前記インターフェースサーバで受信するステップと、
    前記顧客に表示するために明細書を抽出するステップとを有することを特徴とする請求項２１に記載の電子銀行取引方法。
  23. 金融取引を開始して自動的に処理するための自動化された電子銀行取引システムであって、
    遠隔地に位置する銀行の顧客を許可し、自動処理のために金融取引要求を選択的に開始する開始手段と、
    前記金融取引要求を自動的に受信して処理するために適している銀行ホストサーバと、
    前記開始手段から前記銀行ホストサーバに支払取引要求を伝送するために、前記銀行ホストサーバと前記開始手段のデータ通信におけるコンピュータネットワークと、
    前記開始手段と前記コンピュータネットワークの間に位置し、自動的に前記開始手段を前記銀行ホストサーバへインターフェース接続し、かつ、前記銀行ホストサーバと互換性のある読み取り可能な形式に前記金融取引要求を変換するインターフェース手段とを有することを特徴とする電子銀行取引システム。
  24. 前記開始手段と前記銀行ホストサーバ間のデータについて、安全な伝送を確立するセキュリティー手段を有することを特徴とする請求項２３に記載の電子銀行取引システム。
  25. 前記開始手段、前記インターフェース手段及び前記銀行ホストサーバを動作させ、前記金融取引要求に自動的に応答するプログラムミング手段を有し、
    このプログラミング手段によって、前記銀行ホストサーバは前記金融取引を完了し、
    支払取引の完了処理で実行される必要な照合などの追跡工程毎に必要な金融取引の電子記録の全てについての製作物の保証することを特徴とする請求項２３に記載の電子銀行取引システム。
  26. 前記開始手段は、金融取引要求の生成を許可する少なくとも１つのコンピュータと、前記少なくとも１つのコンピュータと前記インターフェース手段との間に接続される前記顧客のローカルコンピュータサーバと、
    前記顧客の金融取引要求に応じて、中間ドキュメント形式の金融取引命令と支払パラメータに関連した各種の必要な全ての履歴とを準備する前記ローカルコンピュータサーバの動作に必要なコンピュータプログラムを格納する中央トランザクションデータベース記憶装置とを有することを特徴とする請求項２３に記載の電子銀行取引システム。
  27. 前記開始手段は、前記ローカルコンピュータサーバと前記コンピュータネットワークとの間に接続された前記顧客のインターフェースコンピュータサーバと、
    前記ローカルコンピュータサーバからの通信において、前記コンピュータネットワークを使用して通信するための形式に変換するために、前記インターフェースサーバを動作させ、かつ前記中間ドキュメント、取引ドキュメント、リターンコード及び前記銀行ホストサーバとの取引に関連するメッセージを格納するにあたって必要なコンピュータプログラムを格納する中央インターフェースデータベース記憶装置とを有することを特徴とする請求項２６に記載の電子銀行取引システム。

JP2004536629A 2002-09-16 2003-09-16 電子銀行取引システム Pending JP2005539316A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US41133002P 2002-09-16 2002-09-16
PCT/US2003/029551 WO2004025430A2 (en) 2002-09-16 2003-09-16 Electronic banking system

Publications (1)

Publication Number Publication Date
JP2005539316A true JP2005539316A (ja) 2005-12-22

Family

ID=31994257

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004536629A Pending JP2005539316A (ja) 2002-09-16 2003-09-16 電子銀行取引システム

Country Status (7)

Country Link
US (1) US20060112011A1 (ja)
EP (1) EP1546960A4 (ja)
JP (1) JP2005539316A (ja)
CN (1) CN1703706A (ja)
AU (1) AU2003270788A1 (ja)
HK (1) HK1079875A1 (ja)
WO (1) WO2004025430A2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101415962B1 (ko) * 2012-11-27 2014-07-04 중소기업은행 단말 거래의 기록 및 재생 방법 및 장치

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030217005A1 (en) * 1996-11-27 2003-11-20 Diebold Self Service Systems, Division Of Diebold, Incorporated Automated banking machine system and method
US20040243441A1 (en) * 2003-04-15 2004-12-02 Siegfried Bocionek Personal and healthcare data financial management system
US7774780B2 (en) * 2004-05-21 2010-08-10 Bea Systems, Inc. Systems and methods for automatic retry of transactions
US7778965B2 (en) * 2006-05-23 2010-08-17 Sap Ag Systems and methods for common instance handling of providers in a plurality of frameworks
US10540651B1 (en) * 2007-07-31 2020-01-21 Intuit Inc. Technique for restricting access to information
US20090281943A1 (en) * 2008-05-07 2009-11-12 Yoggerst A John Systems and Methods for Collecting Bonds and Fines for Warrants and Traffic Tickets
US8719160B1 (en) * 2008-07-21 2014-05-06 Bank Of America Processing payment items
US10643189B1 (en) * 2009-04-30 2020-05-05 Intuit Inc. Software product activation for on-line banking customers
US20110173122A1 (en) * 2010-01-09 2011-07-14 Tara Chand Singhal Systems and methods of bank security in online commerce
US9330076B2 (en) * 2013-01-28 2016-05-03 Virtual StrongBox Virtual storage system and file conversion method
CN104038605B (zh) * 2014-06-04 2016-08-17 福建升腾资讯有限公司 电话pos支付终端交易测试的方法
CN104331827B (zh) * 2014-11-14 2018-07-06 中国建设银行股份有限公司 交易配置生成方法及交易匹配器
CN108921698B (zh) * 2018-07-03 2022-02-25 中国银行股份有限公司 基于全球一体化核心银行系统的分行补录方法及系统
CN111629056B (zh) * 2020-05-27 2023-04-07 浙江百世技术有限公司 一种网络请求处理方法及应用
WO2022043888A1 (en) * 2020-08-25 2022-03-03 Incatorque (Pty) Ltd Transacting
CN112068819B (zh) * 2020-09-08 2023-11-21 中国银行股份有限公司 一种商业汇票系统的切面控制方法及系统
CN115330533A (zh) * 2022-10-14 2022-11-11 好享家舒适智能家居股份有限公司 一种用于智慧工程的多银行流水获取方法

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6058378A (en) * 1995-02-22 2000-05-02 Citibank, N.A. Electronic delivery system and method for integrating global financial services
BR9815131A (pt) * 1997-12-02 2005-05-31 Cash Technologies Inc Rede de transação automatizada, terminal de transação automatizado e, processo para realizar uma transação com um de diversos provedores de serviços a partir de um terminal de transação automatizado
US6286098B1 (en) * 1998-08-28 2001-09-04 Sap Aktiengesellschaft System and method for encrypting audit information in network applications
CA2348935A1 (en) * 1998-11-09 2000-05-18 Onecore Financial Network, Inc. Systems and methods for performing integrated financial transactions
US6738975B1 (en) * 1998-11-18 2004-05-18 Software Ag, Inc. Extensible distributed enterprise application integration system
US6609113B1 (en) * 1999-05-03 2003-08-19 The Chase Manhattan Bank Method and system for processing internet payments using the electronic funds transfer network
US6578015B1 (en) * 1999-08-31 2003-06-10 Oracle International Corporation Methods, devices and systems for electronic bill presentment and payment
EP1126380A1 (en) * 2000-02-16 2001-08-22 Sun Microsystems, Inc. Converting a formatted document into an XML-document
US20020123966A1 (en) * 2000-06-23 2002-09-05 Luke Chu System and method for administration of network financial transaction terminals
US7949600B1 (en) * 2000-06-27 2011-05-24 Western Union Financial Services, Inc. Method for facilitating payment of a computerized transaction
DE10049940A1 (de) * 2000-10-06 2002-04-18 Plecto Ag Tranformierungskonnektor
CA2354372A1 (en) * 2001-02-23 2002-08-23 Efunds Corporation Electronic payment and authentication system with debit and identification data verification and electronic check capabilities
US7134075B2 (en) * 2001-04-26 2006-11-07 International Business Machines Corporation Conversion of documents between XML and processor efficient MXML in content based routing networks
US7904360B2 (en) * 2002-02-04 2011-03-08 Alexander William EVANS System and method for verification, authentication, and notification of a transaction

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101415962B1 (ko) * 2012-11-27 2014-07-04 중소기업은행 단말 거래의 기록 및 재생 방법 및 장치

Also Published As

Publication number Publication date
AU2003270788A8 (en) 2004-04-30
WO2004025430A3 (en) 2004-08-26
WO2004025430A2 (en) 2004-03-25
US20060112011A1 (en) 2006-05-25
EP1546960A4 (en) 2006-04-05
EP1546960A2 (en) 2005-06-29
CN1703706A (zh) 2005-11-30
HK1079875A1 (zh) 2006-04-13
AU2003270788A1 (en) 2004-04-30

Similar Documents

Publication Publication Date Title
US11205160B2 (en) Electronic payment and authentication system with debit and identification data verification and electronic check capabilities
US9373105B2 (en) Method and system for thin client based image and transaction management
US8229808B1 (en) System and method for providing a distributed decisioning environment for processing of financial transactions
US6882986B1 (en) Method for automatic processing of invoices
US9076134B2 (en) Computerized money transfer system and method
US8401965B2 (en) Payment handling
US20040064375A1 (en) Method and system for generating account reconciliation data
JP2005539316A (ja) 電子銀行取引システム
US8527381B2 (en) System and method for authorizing third-party transactions for an account at a financial institution on behalf of the account holder
US20030158811A1 (en) System and method for rules based electronic funds transaction processing
US20010032178A1 (en) Network based loan approval and document origination system
US20050096996A1 (en) Interface for conducting the closing of a real estate sale over a computerized network
US20050165681A1 (en) Method for automatic processing of invoices
US7379907B2 (en) Apparatus, system and method for reporting financial data and remitting funds over an interactive communications network or the like
JP2009098986A (ja) 電子債権仲介システム
KR20020087299A (ko) 외환 서비스 제공 방법
JP2004110160A (ja) 工事保証データ処理方法及び工事保証データ処理システム並びに工事保証データ処理プログラム

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20071225

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080108

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20080401

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20080424

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080708

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080812

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20081224