JP4064664B2 - Bank transaction confirmation system and method - Google Patents

Bank transaction confirmation system and method Download PDF

Info

Publication number
JP4064664B2
JP4064664B2 JP2001379055A JP2001379055A JP4064664B2 JP 4064664 B2 JP4064664 B2 JP 4064664B2 JP 2001379055 A JP2001379055 A JP 2001379055A JP 2001379055 A JP2001379055 A JP 2001379055A JP 4064664 B2 JP4064664 B2 JP 4064664B2
Authority
JP
Japan
Prior art keywords
remittance
information
trustee
consignor
total
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.)
Expired - Lifetime
Application number
JP2001379055A
Other languages
Japanese (ja)
Other versions
JP2003178198A (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.)
Sumitomo Mitsui Banking Corp
Original Assignee
Sumitomo Mitsui Banking Corp
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 Sumitomo Mitsui Banking Corp filed Critical Sumitomo Mitsui Banking Corp
Priority to JP2001379055A priority Critical patent/JP4064664B2/en
Publication of JP2003178198A publication Critical patent/JP2003178198A/en
Application granted granted Critical
Publication of JP4064664B2 publication Critical patent/JP4064664B2/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

【0001】
【発明の属する技術分野】
この発明は、例えばエレクトリックバンキングシステムにおける送金・振込依頼の処理において、送金依頼者以外の第三者による確認及び承認をその処理条件にすることができるシステム及び方法に関するものである。
【0002】
【従来の技術】
昨今、企業等の事務合理化、経費削減ニーズの増加に伴い、限られた経営資源を最大限に活用して発展を続けるための手段として、社外への業務委託(アウトソーシング)が注目されている。
【0003】
このようなアウトソーシングの例として、マンション管理組合の各種経理事務を代行するマンション管理業者がある。このような経理事務の代行業務では、マンション管理業者は、委託先であるマンション管理組合のために各業者宛の振込用データを用意し、このデータを金融機関に持ち込んで振込を依頼する。
【0004】
このような振込の依頼は、例えば振込にかかる資金をまずマンション管理業者の口座に移動させ、このマンション管理業者の口座から上記振込を行う方法(受託者の口座を利用する方法)によって行われている。
【0005】
このような方法によれば、マンション管理業者との間に上記資金の口座引き落としの契約を結んでおいたり、マンション管理組合が必要な資金をマンション管理業者の口座に振り込むことで、以後の振込業務を前記マンション管理業者にアウトソーシングすることができる。
【0006】
【発明が解決しようとする課題】
ところで、上記従来の資金移動代行業務によれば、以下のような解決するべき課題がある。
【0007】
すなわち、前記したような受託者の口座を利用して資金移動を代行させる方法では、事務委託者の資金を一旦受託者の口座に移動させる必要がある。このため当該資金は受託者による不正流用リスクにさらされることになる。また、受託者ではそのような不正流用の意思が全くないにもかかわらず、その可能性の指摘を受けた場合に抗弁する手段がない。
【0008】
また、この他にも事務受託者(マンション管理業者)の口座を介さず、事務委託者(マンション管理組合)の口座を利用して振込を行う方法も考えられる。しかし、この方法では、事務委託者が支払データの内容を事前にチェックする必要があり、多大な時間と手間がかかってしまうという別の問題がある。
【0009】
この発明は、このような事情に鑑みてなされたものであり、事務委託者及び事務受託者双方の不安を取り去り、受託者による安全な送金代行処理を可能にするシステムを提供することを目的とするものである。
【0010】
【課題を解決するための手段】
上記課題を解決するため、この発明の第1の主要な観点によれば、金融機関に設けられたサーバと送金処理を行う金融機関ホストとを有し、所定の送金先への送金手続きの代行を委託する委託者・受託者及び当該送金先の間の銀行取引の確認を行う金融機関システムであって、前記サーバは、前記受託者及び委託者の通信端末と通信ネットワークを介して夫々接続され、このサーバは、前記受託者が作成し、この受託者及び委託者を特定するための情報と送金先の口座の情報と送金先に送金する資金を引き落とす受託者若しくは委託者の口座の情報とを含む送金依頼情報(総合振込データ:以下「総振データ」と略す)を当該受託者の通信端末から通信ネットワークを介して受信して受託者若しくは委託者の銀行口座内の資金を所定の送金先口座へ送金するための送金依頼を受け付けると共に、この総振データを前記金融機関ホストに送信する送金依頼受付部と、前記送金依頼を受け付けた場合に、委託者と受託者との間で締結された送金代行契約の情報を格納する契約情報データベース(DB)にアクセスして、前記総振データに含まれる委託者及び受託者を特定する情報に基いて当該受託者と委託者との間の送金代行契約の情報を確認する契約情報確認部と、送金代行契約が確認できた場合に、この委託者の通信端末に対して総振データを含む送金承認要求情報を作成して通信ネットワークを介して送信し、委託者の通信端末からの送金承認情報を通信ネットワークを介して受信すると共に、前記金融機関ホストに対して送金処理の指示を送信する送金依頼承諾処理部と、を備え、前記金融機関ホストは、前記サーバの送金依頼承諾処理部から送金処理の指示を受信した場合に、前記送金依頼受付部から受信した総振データに含まれる受託者若しくは委託者の口座から送金先の口座に対してこの送金依頼に係る送金処理を実行する送金処理部を有することを特徴とする銀行取引確認システムが提供される。
【0011】
このような構成によれば、従来行うことができなかった送金形態、すなわち、委託者に代わって事務の受託者が送金を依頼することで、この委託者の口座から送金することが可能になる。そして、この場合、委託者の承認がなければこれを実行できないようにしたから、事務受託者の信頼性を担保することができる。また、送金依頼を受け取った際に契約情報DBを参照することで、委託者の承認を要する送金依頼であることを識別する事が容易に行え、これに基づいて以後の処理を進めていくことができる。
【0012】
ここで、前記サーバの送金依頼承諾処理部は、前記委託者の通信端末からの送金承認情報を通信ネットワークを介して受信したことに基づいて総振データをロックする総振データロック指示情報を金融機関ホストに出力するものであり、前記金融機関ホストは、前記総振データロック指示情報を受信した場合に、総振データのロックを実行する総振データロック実行部をさらに備え、前記金融機関ホストの送金処理部は、総振データがロックされていることに基づいて前記送金依頼に係る送金処理を実行するものであることが好ましい。このような構成によれば、委託者が送金依頼をロックした後は受託者の方で勝手にその内容を変更することができなくなる。
【0013】
また、前記サーバは、前記委託者の通信端末から要求を通信ネットワークを介して受信した場合当該委託者の通信端末に対して前記総振データを出力する送金依頼内容出力部をさらに有することが好ましい。このような構成によれば、委託者が任意の時に受託者がなした送金依頼の内容を確認することができる。
【0017】
また、前記契約情報DBは、送金代行契約の情報に加えて、委託者が送金を承認/否認する場合の送金承認情報を受託者及び委託者の情報、若しくは契約情報に関連付けて格納するものである。この場合、前記契約情報格納部は、受託者毎に異なる送金承認情報を委託者の識別情報若しくは契約情報に関連付けて格納するものである。
【0018】
このような構成によれば、委託者の承認を受ける際のセキュリティを高めることができるから、より信頼性を向上させることが可能になる。
【0019】
さらにこのシステムは、前記サーバの送金依頼承諾処理部は、前記委託者の通信端末から送金否認情報を通信ネットワークを介して受信した場合に、この総振データの取消しを指示する情報を前記金融機関ホストに対して出力する総振取消指示出力部を有し、前記金融機関ホストは、総振データ取消指示を受信した場合に、該当する総振データの取消しを実行する総振取消実行部をさらに備えた。このような構成によれば、委託者が送金依頼を取消すことができるから、受託者への信頼性を担保することが可能になる。
【0022】
この発明の第2の主要な観点によれば、金融機関に設けられたサーバと送金処理を行う金融機関ホストとを有する銀行取引確認システムによって、所定の送金先への送金手続きの代行を委託する委託者・受託者及び当該送金先の間の銀行取引の確認を行う方法であって、前記サーバは、前記受託者及び委託者の通信端末と通信ネットワークを介して夫々接続され、この方法は、前記サーバの送金依頼受付部が、前記受託者が作成し、この受託者及び委託者を特定するための情報と送金先の口座の情報と送金先に送金する資金を引き落とす受託者若しくは委託者の口座の情報とを含む送金依頼情報(総合振込データ:以下「総振データ」と略す)を当該受託者の通信端末から通信ネットワークを介して受信して受託者若しくは委託者の銀行口座内の資金を所定の送金先口座へ送金するための送金依頼を受け付けると共に、この総振データを前記金融機関ホストに送信する送金依頼受付工程と、前記サーバの契約情報確認部が、前記送金依頼を受け付けた場合に、委託者と受託者との間で締結された送金代行契約の情報を格納する契約情報データベース(DB)にアクセスして、前記総振データに含まれる委託者及び受託者を特定する情報に基いて当該受託者と委託者との間の送金代行契約の情報を確認する契約情報確認工程と、前記サーバの送金依頼承諾処理部が、送金代行契約が確認できた場合に、この委託者の通信端末に対して総振データを含む送金承認要求情報を作成して通信ネットワークを介して送信し、委託者の通信端末からの送金承認情報を通信ネットワークを介して受信すると共に、前記金融機関ホストに対して送金処理の指示を送信する送金依頼承諾処理工程と、前記金融機関ホストの送金処理部が、前記サーバの送金依頼承諾処理部から送金処理の指示を受信した場合に、前記送金依頼受付部から受信した総振データに含まれる受託者若しくは委託者の口座から送金先の口座に対してこの送金依頼に係る送金処理を実行する送金処理工程とを有することを特徴とする銀行取引確認方法が提供される。
【0023】
このような構成によれば、前記第1の観点による発明で実施可能な方法を提供することができる。
【0026】
なお、この発明のその他の特徴と顕著な効果は次の発明の実施の形態の項及び図面を参照することで当業者にとってより明確となる。
【0027】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づき説明する。
【0028】
この発明は、委託者の依頼を受けた受託者が委託者のための送金事務を代行する場合に、委託者がその都度送金に対する承認を与えることを可能にするためのシステム及び方法である。
【0029】
この発明の実施形態としては、大きく分けて図1(a)に示すように受託者である代行会社Zの口座1から送金を行うものと、図1(b)に示すように委託者Aの口座2から直接送金を行うものとに分けられる。以下、まず、代行会社Zの口座から送金を行う場合(図1(a))について説明し、その後、委託者Aの口座から送信する場合(図1(b))について説明する。
【0030】
図1(a)の場合、代行会社Zと委託者Aとの間の取決めにより、委託者Aが所定の期日に所定額の資金をZ社口座1に移動する(図にステップA1で示す)。このことで、委託者Aの資金がZ社口座1から各業者B〜Dに送金可能になる。
【0031】
ついで、代行会社Zは、委託者Aのために総合振込データ(以下「総振データ」と略す)を作成し、金融機関システム10に送る(ステップA2)。ここで総振データとは、複数の振込先及び振込先毎の振込金額を含むデータである。
【0032】
この総振データを受け取った金融機関システム10は、その内容を委託者Aに伝え、委託者Aの承認を受けてデータにロックをかける(ステップA3)。そして、このロックがかかったデータに基づいて各業者B〜Dへの振込処理を行うようにする(ステップA4)。
【0033】
このような処理によれば、代行会社Zが、自己の口座1から委託者Aのために送金をする場合に、委託者Aがその内容を確認して承認を与えなければこれを実行できない。これにより、代行会社Zの信用を担保することが可能になる。
【0034】
以上のような処理を可能にするため、この実施形態に係る金融機関システム10は図2に示すように構成されている。
【0035】
すなわち、この金融機関システム10は、Web上で前記総振データを受け付けて処理するEBサーバ12と、このEBサーバ12で受け付けたデータに基づいて送金処理を行う金融機関ホスト13と、前記送金に関して第三者である委託者Aの承認を得る第三者承認サーバ14と、この第三者承認に基づいて前記金融機関ホスト13に対して前記総振データをロックするように指示するデータロック要求サーバ15とを有する。
【0036】
前記代行会社Zで用意された総振データは、前記EBサーバ12によって受け取られる(ステップB1)。このEBサーバ12は、総振データ送信部17を有し、この総振データ送信部17は、前記代行会社Zより受信した総振データを前記金融機関ホスト13及び第三者承認サーバ14へと送信する(ステップB2、B3)。
【0037】
ここで、前記総振データには、図3に示すように、送金依頼手続(総振データの作成及びEBサーバ12への送信)を行う代行会社Zの情報の他に委託者Aの情報が含まれており、代行送金であることが識別可能になっている。そして、前記EBサーバ12は、これらの情報を図2に18で示す契約情報DBにアクセスして確認した後、前記総振データを前記第三者承認サーバ14に送信するようになっている。
【0038】
なお、この契約情報DB18に登録された各送金代行契約の情報には、後で説明する承認パスワードと否認パスワードがこの契約と関連付けて登録されているものとする。
【0039】
前記第三者承認サーバ14は、第三者である委託者Aに承認を求めてこれを受信する第三者承認要求部19と、第三者から得た承認情報を前記データロック要求サーバ15に送信する承認情報送信部20と、前記EBサーバ12から送信されたデータの内容を保管、蓄積する電子文書保管部21と、送金期限に基づいて承認を得る期限を管理する承認期限管理部22とを有する。
【0040】
前記第三者承認要求部19は、前記総振データを前記電子文書保管部21に格納すると共に、これを含む総振データ掲示メール23を作成し、委託者Aへ送信する機能を有する(ステップB4)。このことによって、前記電子文書保管部21内の各総振データに送信済ステータスが付されることになる。
【0041】
前記委託者Aは、前記第三者承認要求部19から送信された総振データ掲示メール23によって、総振データの内容確認を行うことができる。内容確認の結果、承認を行う場合には、委託者Aは、その承認を所定の承認パスワードと共に前記第三者承認サーバ14へ返す(ステップB5)。一方、否認する場合には、否認を所定の否認パスワードと共に前記第三者承認サーバ14に返す(ステップB6)。
【0042】
この処理のため、例えば前記総振データ掲示メール23には、第三者承認パスワード若しくは否認パスワードの入力ボックス、承認ボタン及び否認ボタンが設けられていることが好ましい。また、前記第三者承認要求部19は、委託者Aからの要求に応じてWebページ上で前記総振データを含む承認/否認画面を表示する機能を備えているものとする。
【0043】
前記第三者承認の期限は前記承認期限管理部22によって管理されるようになっている。そして、前記委託者Aからの承認/否認パスワードを所定の期間内に受け取らない場合には、前記委託者Aに対して再度掲示メール23を送信するように指示する。
【0044】
前記委託者Aから承認/否認パスワードを受け取った前記第三者承認要求部19は、これに基づいて前記総振データ内容が前記委託者Aにより承認若しくは否認されたことを通知するためのメール24を前記代行会社Zに対して送信する(ステップB7)。また、前記承認情報送信部20は、委託者Aから受け取った承認パスワード若しくは否認パスワードをデータロック要求サーバ15へ送信する。(ステップB8)。ここで、前記承認情報送信部20による送信履歴は、上記と同様にすべて前記電子文書保管部21に保管、蓄積される。
【0045】
前記データロック要求サーバ15は、承認データ受取部25と、総振データロック指示出力部26と、総振取消指示出力部27とを有する。承認データ受取部25は、前記第三者承認サーバ14から承認パスワード若しくは否認パスワードを受け取る機能を有する。前記総振データロック指示出力部26は、承認パスワードに基づいて前記金融機関ホスト13に対して総振データのロックを指示する(ステップB9)。また総振取消指示出力部27は、否認パスワードに基づいて前記金融機関ホスト13に対して総振の取消を指示する(ステップB9)。
【0046】
一方、前記金融機関ホスト13は、総振データのロックを実行する総振データロック実行部30と、前記代行会社Zからの合計報告を管理する合計報告管理部31と、当該Z社口座からの送金を処理する送金処理部32と、総振の取消を実行する総振取消実行部33とからなる。前記総振データロック実行部30は、前記データロック要求サーバ15から総振データロック要求を受信すると、前記委託者Aが承認した総振データのロックを行う。前記合計報告(代行会社Zによる確認)は、前記委託者Aからの承認を示すメール24を見た前記代行会社Zによってなされ、前記合計報告管理部31によって取得される(ステップB10)。
【0047】
このようにして総振データがロックされ、前記合計報告管理部31が合計報告を取得したならば、前記送金処理部32が、当該Z社口座から前記総振データに基づいて送金処理を実行する(ステップB11)。
【0048】
また、この金融機関ホスト13は、総振取消実行部33を有する。この総振取消実行部33は、前記データロック要求サーバ15から総振取消指示を受け取ったこと、及び前記代行会社Zから取消承認を受けたことに基づいて総振データの取消を行う。なお、この総振取消実行部33は、前記総振データがロックされている場合には、このロックを解除した後にその取消を行うようになっている。
【0049】
このような構成によれば、代行会社Zが自己の口座から送金を行う場合に、第三者である委託者Aがその確認及び承認を行うことができ、その承認がなければ送金を行うことができないようにすることができる。このことにより、送金代行業者に対する委託者の信頼性を向上させることが可能になる。
【0050】
次に、図1(b)の場合、すなわち、委託者Aの口座から直接送金を行う場合について説明する。
【0051】
この場合は、この図1(a)の場合と異なり、Z社の口座1は使用されず、委託者Aの口座2から直接各業者B〜Dに送金を行う。
【0052】
この例でも、代行会社Zは、委託者Aのために総振データを作成し、金融機関システム10のEBサーバ12に送信するようになっている(ステップC1)。
【0053】
この総振データは、図4に示すように、送金手続者のフィールドには図3と同様にZ社の情報が特定されているが、口座番号のフィールドにZ社の口座番号ではなく、委託者Aの口座番号が特定されている。
【0054】
前記総振データを受け取った金融機関システム10は、その内容を委託者Aに伝え、委託者Aの承認を受けてデータにロックをかける(ステップC2)。そして、このロックがかかったデータに基づいて各業者B〜Dへの振込処理を行う(ステップC3)。
【0055】
このような処理によれば、委託者Aがその振込データの内容を確認して承認を与えなければこれを実行できないようにすることができる。
【0056】
このような処理を行う前記金融機関システム10は、図3で説明した構成と同じ構成であれば良い。ここで、この金融機関システム10は、前記口座番号のフィールドを参照して、委託者Aの口座番号であるかZ社の口座番号であるかによって、上記図1(a)と(b)の処理を振り分けて実行することができる。
【0057】
そして、振り分けた結果、図1(b)の送金である場合には、前記金融機関ホスト13は、図2にD1で示すように、前記委託者Aの口座から送金を行うように指示を作成する。
【0058】
なお、この発明は上記一実施形態に限定されるものではなく、発明の要旨を変更しない範囲で種々変形可能である。
【0059】
例えば、情報の閲覧及び承認をWEB上で行うようにしたが、携帯電話等の携帯端末から行うようにしても良い。
【0060】
また、前記実施形態では総振データの受信はWeb上で行うようにしているが、これに限定されるものではない。
【0061】
また、承認手続は、メールに限定されるものではなく、ファックスや手紙の送受信で行うようにしても良いし、電話で行うようにしても良い。
【0062】
さらに、前記承認パスワード及び否認パスワードは、委託者が複数の代行会社を利用している場合、全ての代行会社に共通のものであっても良いし、異なるものであっても良い。
【0063】
【発明の効果】
以上説明したように、この発明によれば、事務委託者及び事務受託者双方の不安を取り去り、受託者による安全な送金処理を可能にするシステム及び方法を提供することができる。
【図面の簡単な説明】
【図1】この発明の一実施形態の処理を簡単に説明する模式図。
【図2】同じく、金融機関システムの概略構成図。
【図3】図1(a)の場合の総振データの構成を説明するための図。
【図4】図1(b)の場合の総振データの構成を説明するための図。
【符号の説明】
Z…代行会社
A…委託者
10…金融機関システム
12…EBサーバ
13…金融機関ホスト
14…第三者承認サーバ
15…データロック要求サーバ
17…総振データ送信部
18…契約情報DB
19…第三者承認要求部
20…承認情報送信部
21…電子文書保管部
22…承認期限管理部
23…総振データ掲示メール
24…代行会社へのメール
25…承認データ受取部
26…総振データロック指示出力部
27…総振取消指示出力部
30…総振データロック実行部
31…合計報告管理部
32…送金処理部
33…総振取消実行部
[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a system and method that can make confirmation and approval by a third party other than the remittance requester the processing condition in remittance / transfer request processing in an electric banking system, for example.
[0002]
[Prior art]
In recent years, with the rationalization of business and the need for cost reduction of companies, outsourcing has been attracting attention as a means for making the best use of limited management resources and continuing development.
[0003]
As an example of such outsourcing, there is a condominium manager who performs various accounting operations of the condominium management association. In such accounting work, the condominium management company prepares transfer data for each contractor for the condominium management association, which is a consignee, and brings this data to a financial institution to request a transfer.
[0004]
Such a transfer request is made, for example, by transferring funds to the apartment manager's account first and transferring the money from the apartment manager's account (using the trustee's account). Yes.
[0005]
According to such a method, the above-mentioned funds are debited with the condominium manager, or the necessary funds are transferred to the condominium manager's account by the condominium management association. Can be outsourced to the condominium manager.
[0006]
[Problems to be solved by the invention]
By the way, according to the conventional fund transfer agency business, there are the following problems to be solved.
[0007]
That is, in the method of transferring funds using the trustee's account as described above, it is necessary to temporarily transfer the money of the office trustee to the account of the trustee. This exposes the funds to the risk of misappropriation by the trustee. Moreover, even though the trustee has no intention of such misappropriation, there is no means to defend when the possibility is pointed out.
[0008]
In addition to this, there may be a method of making a transfer using an account of an office contractor (apartment management association) without using an account of an office trustee (apartment management company). However, with this method, there is another problem that it is necessary for the business consignor to check the contents of the payment data in advance, which takes a lot of time and effort.
[0009]
The present invention has been made in view of such circumstances, and an object of the present invention is to provide a system that removes the anxiety of both the business consignor and the business trustee and enables safe remittance processing by the trustee. To do.
[0010]
[Means for Solving the Problems]
In order to solve the above-mentioned problem, according to a first main aspect of the present invention, a server having a server provided in a financial institution and a financial institution host for performing remittance processing, acting for a remittance procedure to a predetermined remittance destination A financial institution system for confirming bank transactions between a consignor / trustee and a remittance destination, and the server is connected to a communication terminal of the trustee and the consignor via a communication network, respectively. This server is created by the trustee and includes information for identifying the trustee and the trustee, information on the account of the remittance destination, and information on the account of the trustee or trustee who withdraws funds to be transferred to the remittance destination. Remittance request information (general transfer data: hereinafter referred to as “total transfer data”) from the trustee 's communication terminal via the communication network, and the funds in the trustee's or trustee's bank account money transfer A remittance request for remittance to an account is accepted, and a remittance request accepting unit that transmits the total transfer data to the financial institution host, and when the remittance request is accepted, it is concluded between the consignor and the trustee. and remittance proxy accesses the contract information database for storing information of the contract (DB), transfer between the consignor and the accession based on the information identifying the trustee's the consignor included in the total vibration data and contract information confirming unit to confirm the information of the agency contract, if the remittance agency contract could be confirmed, via a communication network to create a remittance approval request information, including the total vibration data to the communication terminal of the consignor transmitted, which receives via the communications network money transfer authorization information from the communication terminal consignor, the remittance acceptance processing unit that transmits an instruction to transfer process to the financial institution host, the For example, the financial institution host, when receiving the instruction of remittance processing from remittance consent processing unit of the server, remittance from the trustees or the consignor of the account is included in the total vibration data received from the remittance receiving unit There is provided a bank transaction confirmation system characterized by having a remittance processing unit for executing remittance processing related to the remittance request for a previous account .
[0011]
According to such a configuration, a remittance form that could not be performed conventionally, that is, it is possible to remit money from the account of the consignor by requesting remittance on behalf of the consignor. . And in this case, since it was made impossible to execute this without the approval of the consignor, the reliability of the office trustee can be ensured. In addition, by referring to the contract information DB when a remittance request is received, it is easy to identify a remittance request that requires the approval of the consignor, and the subsequent processing proceeds based on this request. Can do.
[0012]
Here, the remittance request acceptance processing unit of the server includes total transfer data lock instruction information for locking the total transfer data based on receiving the remittance approval information from the communication terminal of the entrustor via the communication network. Output to a financial institution host, and the financial institution host further includes a total data lock execution unit that locks the total data when receiving the total data lock instruction information. It is preferable that the remittance processing unit of the host executes the remittance process related to the remittance request based on the fact that the total transfer data is locked. According to such a configuration, after the consignor locks the remittance request, the contents cannot be changed without permission by the consignor.
[0013]
Further, the server, when receiving via the communication network a request from the communication terminal of the consignor, further comprising a transfer request content output unit which outputs the total vibration data to the communication terminal of the consignor It is preferable. According to such a configuration, the contents of the remittance request made by the trustee at any time can be confirmed.
[0017]
Further, the contract information DB stores remittance approval information when the consignor approves / denies remittance in addition to the information of the remittance agent contract in association with the trustee and consignor information or contract information. is there. In this case, the contract information storage unit stores remittance approval information that is different for each trustee in association with the identification information or contract information of the trustee.
[0018]
According to such a configuration, it is possible to increase the security when receiving the approval of the consignor, and thus it is possible to further improve the reliability.
[0019]
Further, in this system, when the remittance request acceptance processing unit of the server receives remittance refusal information from the communication terminal of the consignor via a communication network, information indicating the cancellation of the total transfer data is sent to the financial A total transfer cancellation instruction output unit for outputting to the institution host, and the financial institution host has a total cancellation execution unit for canceling the corresponding total transfer data when receiving the total transfer data cancellation instruction. Further provided. According to such a configuration, since the consignor can cancel the remittance request, it becomes possible to ensure the reliability to the trustee.
[0022]
According to the second main aspect of the present invention, a bank transaction confirmation system having a server provided in a financial institution and a financial institution host for performing remittance processing entrusts a proxy for a remittance procedure to a predetermined remittance destination. A method for confirming a bank transaction between a consignor / trustee and the remittance destination, wherein the server is connected to a communication terminal of the trustee and the consignor via a communication network, respectively. The remittance request acceptance unit of the server is created by the trustee and includes information for identifying the trustee and the consignor, information on the account of the remittance destination, and the trustee or consignor who withdraws funds to be transferred to the remittance destination. remittance information including the account of the information (total transfer data: hereinafter referred to as "total vibration data") was received through the communication network from the communication terminal of the trustee, the trustee or the consignor of the bank opening Funds inner with accepting remittance for transfer to a predetermined transfer destination account, and remittance request reception step of transmitting the total vibration data to the financial institution host, contract information confirmation section of the server, the remittance The contract information database (DB) that stores the information of the remittance agent contract concluded between the consignor and the consignor, and the consignor and the consignor included in the general transfer data are accessed. The contract information confirmation process for confirming the information of the remittance agent contract between the trustee and the consignor based on the information to be identified, and when the remittance request acceptance processing unit of the server has confirmed the remittance agent contract, the clients' creates a remittance approval request information containing the total vibration data to the communication terminal and transmitted via the communication network via the communication network money transfer authorization information from the communication terminal consignor While Shin, the remittance acceptance processing step of transmitting an indication of the remittance processing to the financial institution host, remittance processing unit of the financial institution host, receiving an instruction transfer processing from remittance acceptance processing unit of the server A remittance processing step for executing remittance processing related to the remittance request from the account of the trustee or the consignor included in the total transfer data received from the remittance request acceptance unit to the remittance destination account. A bank transaction confirmation method is provided.
[0023]
According to such a configuration, it is possible to provide a method that can be implemented by the invention according to the first aspect.
[0026]
Other features and remarkable effects of the present invention will become clearer to those skilled in the art with reference to the following description of the embodiments of the present invention and the drawings.
[0027]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[0028]
The present invention is a system and method for enabling a consignor to give approval for remittance each time when a trustee who has received a request from the consignor performs remittance work for the consignor.
[0029]
As an embodiment of the present invention, as shown in FIG. 1A, the remittance is performed from the account 1 of the agency company Z, which is the trustee, and as shown in FIG. It can be divided into direct money transfer from account 2. Hereinafter, a case where remittance is performed from the account of the agency company Z (FIG. 1A) will be described first, and then a case where transmission is performed from the account of the consignor A (FIG. 1B) will be described.
[0030]
In the case of FIG. 1A, the contractor A moves a predetermined amount of funds to the Z company account 1 on a predetermined date according to an agreement between the agency company Z and the contractor A (indicated by step A1 in the figure). . As a result, the money of the consignor A can be transferred from the Z company account 1 to each of the traders B to D.
[0031]
Next, the agency company Z creates general transfer data (hereinafter abbreviated as “total transfer data”) for the consignor A and sends it to the financial institution system 10 (step A2). Here, the total transfer data is data including a plurality of transfer destinations and transfer amounts for each transfer destination.
[0032]
The financial institution system 10 that has received this total data transmits the contents to the consignor A and locks the data after receiving approval from the consignor A (step A3). Then, a transfer process to each of the traders B to D is performed based on the locked data (step A4).
[0033]
According to such processing, when the agency company Z remits money for the consignor A from its own account 1, it cannot be executed unless the consignor A confirms the contents and gives approval. Thereby, it becomes possible to secure the credit of the agency company Z.
[0034]
In order to enable the processing as described above, the financial institution system 10 according to this embodiment is configured as shown in FIG.
[0035]
That is, the financial institution system 10 includes an EB server 12 that receives and processes the total transfer data on the Web, a financial institution host 13 that performs remittance processing based on the data received by the EB server 12, and the remittance. A third party approval server 14 that obtains the approval of the consignor A, who is a third party, and a data lock request that instructs the financial institution host 13 to lock the total data based on the third party approval. And a server 15.
[0036]
The total transfer data prepared by the agency company Z is received by the EB server 12 (step B1). The EB server 12 has a total transfer data transmission unit 17, which transfers the total transfer data received from the agency company Z to the financial institution host 13 and the third party approval server 14. Transmit (steps B2 and B3).
[0037]
Here, as shown in FIG. 3, the total transfer data includes the information of the consignor A in addition to the information of the agent company Z that performs the remittance request procedure (preparation of total transfer data and transmission to the EB server 12). It is included, and it is possible to identify that it is a proxy transfer. The EB server 12 accesses the contract information DB indicated by 18 in FIG. 2 and confirms the information, and then transmits the total distribution data to the third party approval server 14.
[0038]
It is assumed that an approval password and a denial password, which will be described later, are registered in association with this contract in the information of each remittance agent contract registered in the contract information DB 18.
[0039]
The third party approval server 14 asks the third party consignor A for approval and receives it, and receives the approval information obtained from the third party from the data lock request server 15. An approval information transmitting unit 20 for transmitting data, an electronic document storage unit 21 for storing and storing the contents of data transmitted from the EB server 12, and an approval time limit managing unit 22 for managing a time limit for obtaining approval based on the remittance time limit. And have.
[0040]
The third party approval request unit 19 has a function of storing the total distribution data in the electronic document storage unit 21, creating a total distribution data posting mail 23 including the data, and transmitting it to the consignor A (step) B4). As a result, a transmitted status is assigned to each total data in the electronic document storage unit 21.
[0041]
The consignor A can check the contents of the total data by using the total data posting mail 23 transmitted from the third party approval request unit 19. As a result of the content confirmation, when the approval is made, the consignor A returns the approval together with a predetermined approval password to the third party approval server 14 (step B5). On the other hand, in the case of denial, the denial is returned to the third party approval server 14 together with a predetermined denial password (step B6).
[0042]
For this process, for example, the total data posting mail 23 is preferably provided with a third-party approval password or rejection password input box, an approval button, and a rejection button. The third party approval request unit 19 has a function of displaying an approval / denial screen including the total data on the Web page in response to a request from the consignor A.
[0043]
The third party approval time limit is managed by the approval time limit management unit 22. If the approval / denial password from the consignor A is not received within a predetermined period, the consignor A is instructed to send the posting mail 23 again.
[0044]
Upon receipt of the approval / denial password from the consignor A, the third party approval request unit 19 notifies the fact that the total data content has been approved or rejected by the consignor A based on this. Is transmitted to the agency company Z (step B7). Further, the approval information transmission unit 20 transmits the approval password or the denial password received from the consignor A to the data lock request server 15. (Step B8). Here, the transmission history by the approval information transmission unit 20 is all stored and accumulated in the electronic document storage unit 21 in the same manner as described above.
[0045]
The data lock request server 15 includes an approval data receiving unit 25, a total data lock instruction output unit 26, and a total data cancellation instruction output unit 27. The approval data receiving unit 25 has a function of receiving an approval password or a denial password from the third-party approval server 14. The total data lock instruction output unit 26 instructs the financial institution host 13 to lock the total data based on the approval password (step B9). The total cancellation cancellation instruction output unit 27 instructs the financial institution host 13 to cancel the total allocation based on the denial password (step B9).
[0046]
On the other hand, the financial institution host 13 includes a total data lock execution unit 30 that locks total data, a total report management unit 31 that manages a total report from the agency company Z, and a Z account from the Z company account. It consists of a remittance processing unit 32 that processes remittance and a total transfer cancellation execution unit 33 that executes total transfer cancellation. When receiving the total data lock request from the data lock request server 15, the total data lock execution unit 30 locks the total data approved by the consignor A. The total report (confirmation by the proxy company Z) is made by the proxy company Z who has seen the mail 24 indicating the approval from the consignor A, and is acquired by the total report management unit 31 (step B10).
[0047]
In this way, if the total transfer data is locked and the total report management unit 31 acquires the total report, the remittance processing unit 32 executes the remittance process from the Z company account based on the total transfer data. (Step B11).
[0048]
Further, the financial institution host 13 has a total cancellation executing unit 33. The total reversal execution unit 33 cancels the total relocation data based on the receipt of the total reversal cancellation instruction from the data lock request server 15 and the revocation approval from the agency company Z. In addition, when the total shake data is locked, the total shake cancel execution unit 33 cancels the lock after releasing the lock.
[0049]
According to such a configuration, when the proxy company Z transfers money from its own account, the consignor A, a third party, can confirm and approve it, and if there is no approval, transfer money Can not be. This makes it possible to improve the reliability of the consignor with respect to the remittance agent.
[0050]
Next, the case of FIG. 1B, that is, the case of direct remittance from the account of the consignor A will be described.
[0051]
In this case, unlike the case of FIG. 1A, the account 1 of the company Z is not used, and remittance is directly performed from the account 2 of the consignor A to each of the suppliers B to D.
[0052]
Also in this example, the agency company Z creates total data for the consignor A and transmits it to the EB server 12 of the financial institution system 10 (step C1).
[0053]
As shown in FIG. 4, in the total transfer data, the information of company Z is specified in the remittance proctor's field as in FIG. 3, but the account number field is not the account number of company Z, but is entrusted. The account number of the person A is specified.
[0054]
The financial institution system 10 that has received the total data transfers the contents to the consignor A and locks the data after receiving the approval of the consignor A (step C2). Then, the transfer process to each of the traders B to D is performed based on the locked data (step C3).
[0055]
According to such processing, it is possible to prevent the consignor A from executing it unless the transfer data is confirmed and approved.
[0056]
The said financial institution system 10 which performs such a process should just be the same structure as the structure demonstrated in FIG. Here, the financial institution system 10 refers to the account number field and determines whether the account number of the consignor A or the account number of the company Z is shown in FIGS. 1 (a) and 1 (b). Processing can be distributed and executed.
[0057]
If the remittance result is the remittance of FIG. 1B, the financial institution host 13 creates an instruction to remit money from the account of the consignor A, as indicated by D1 in FIG. To do.
[0058]
In addition, this invention is not limited to the said one Embodiment, A various deformation | transformation is possible in the range which does not change the summary of invention.
[0059]
For example, information browsing and approval are performed on the WEB, but may be performed from a mobile terminal such as a mobile phone.
[0060]
In the above embodiment, the total data is received on the Web, but the present invention is not limited to this.
[0061]
In addition, the approval procedure is not limited to e-mail, and may be performed by sending and receiving a fax or a letter, or may be performed by telephone.
[0062]
Further, when the consignor uses a plurality of agency companies, the approval password and the denial password may be common to all agency companies or may be different.
[0063]
【The invention's effect】
As described above, according to the present invention, it is possible to provide a system and method that removes the anxiety of both the business consignor and the business consignor and enables safe remittance processing by the consignor.
[Brief description of the drawings]
FIG. 1 is a schematic diagram for briefly explaining the processing of an embodiment of the present invention.
FIG. 2 is a schematic configuration diagram of a financial institution system.
FIG. 3 is a diagram for explaining the configuration of total oscillation data in the case of FIG.
FIG. 4 is a diagram for explaining the configuration of total vibration data in the case of FIG.
[Explanation of symbols]
Z ... Agency company A ... Consignor 10 ... Financial institution system 12 ... EB server 13 ... Financial institution host 14 ... Third party approval server 15 ... Data lock request server 17 ... Total data transmission unit 18 ... Contract information DB
19 ... Third-party approval request unit 20 ... Approval information transmission unit 21 ... Electronic document storage unit 22 ... Approval time limit management unit 23 ... Total transfer data posting email 24 ... Email to agency 25 ... Approval data reception unit 26 ... Total transfer Data lock instruction output unit 27 ... Total transfer cancellation instruction output unit 30 ... Total transfer data lock execution unit 31 ... Total report management unit 32 ... Remittance processing unit 33 ... Total transfer cancellation execution unit

Claims (7)

金融機関に設けられたサーバと送金処理を行う金融機関ホストとを有し、所定の送金先への送金手続きの代行を委託する委託者・受託者及び当該送金先の間の銀行取引の確認を行う金融機関システムであって、
前記サーバは、前記受託者及び委託者の通信端末と通信ネットワークを介して夫々接続され、
このサーバは、
前記受託者が作成し、この受託者及び委託者を特定するための情報と送金先の口座の情報と送金先に送金する資金を引き落とす受託者若しくは委託者の口座の情報とを含む送金依頼情報(総合振込データ:以下「総振データ」と略す)を当該受託者の通信端末から通信ネットワークを介して受信して受託者若しくは委託者の銀行口座内の資金を所定の送金先口座へ送金するための送金依頼を受け付けると共に、この総振データを前記金融機関ホストに送信する送金依頼受付部と、
前記送金依頼を受け付けた場合に、委託者と受託者との間で締結された送金代行契約の情報を格納する契約情報データベース(DB)にアクセスして、前記総振データに含まれる委託者及び受託者を特定する情報に基いて当該受託者と委託者との間の送金代行契約の情報を確認する契約情報確認部と、
送金代行契約が確認できた場合に、この委託者の通信端末に対して総振データを含む送金承認要求情報を作成して通信ネットワークを介して送信し、委託者の通信端末からの送金承認情報を通信ネットワークを介して受信すると共に、前記金融機関ホストに対して送金処理の指示を送信する送金依頼承諾処理部と、を備え、
前記金融機関ホストは、前記サーバの送金依頼承諾処理部から送金処理の指示を受信した場合に、前記送金依頼受付部から受信した総振データに含まれる受託者若しくは委託者の口座から送金先の口座に対してこの送金依頼に係る送金処理を実行する送金処理部を有する
ことを特徴とする銀行取引確認システム。
Confirmation of bank transactions between a consignor / trustee who entrusts the delegation of remittance procedures to a specified remittance party and a server provided at the financial institution and a remittance processing host that performs remittance processing A financial institution system that performs
The server is connected to the trustee and the communication terminal of the consignor via a communication network, respectively.
This server
Remittance request information created by the trustee and including information for identifying the trustee and the trustee, information on the account of the remittance destination, and information on the account of the trustee or trustee who withdraws funds to be transferred to the remittance destination (General transfer data: hereinafter referred to as “total transfer data”) is received from the trustee 's communication terminal via the communication network, and the funds in the bank account of the trustee or the trustee are transferred to the specified payee account. A remittance request accepting unit for transmitting the total transfer data to the financial institution host;
When the remittance request is received, the contract information database (DB) that stores information on the remittance agent contract concluded between the consignor and the consignor is accessed , and the consignor included in the total transfer data and A contract information confirmation unit for confirming information on a remittance agent contract between the trustee and the consignor based on information identifying the trustee;
If the remittance agency contract could be confirmed, the total vibration data to create a remittance approval request information, including to send via the communication network, remittance approval information from the communication terminal of the consignor to the communication terminal of the consignor which receives via a communication network, and a remittance acceptance processing unit that transmits an instruction to transfer process to the financial institution host,
When the financial institution host receives a remittance processing instruction from the remittance request acceptance processing unit of the server, the financial institution host receives the remittance destination from the account of the trustee or the consignor included in the total transfer data received from the remittance request reception unit . A bank transaction confirmation system comprising: a remittance processing unit that executes remittance processing related to the remittance request for an account .
請求項1記載の銀行取引確認システムにおいて、
前記サーバの送金依頼承諾処理部は、前記委託者の通信端末からの送金承認情報を通信ネットワークを介して受信したことに基づいて総振データをロックする総振データロック指示情報を金融機関ホストに出力するものであり、
前記金融機関ホストは、前記総振データロック指示情報を受信した場合に、総振データのロックを実行する総振データロック実行部をさらに備え、
前記金融機関ホストの送金処理部は、総振データがロックされていることに基づいて前記送金依頼に係る送金処理を実行するものである
ことを特徴とする銀行取引確認システム。
In the bank transaction confirmation system according to claim 1,
The remittance request acceptance processing unit of the server receives total transfer data lock instruction information for locking the total transfer data based on receiving remittance approval information from the communication terminal of the consignor via a communication network. Output to
The financial institution host further includes a total data lock execution unit that locks the total data when receiving the total data lock instruction information,
The bank transaction confirmation system, wherein the remittance processing unit of the financial institution host executes remittance processing related to the remittance request based on the fact that total transfer data is locked.
請求項1記載の銀行取引確認システムにおいて、
前記サーバは、前記委託者の通信端末から要求を通信ネットワークを介して受信した場合当該委託者の通信端末に対して前記総振データを出力する送金依頼内容出力部をさらに有することを特徴とする銀行取引確認システム。
In the bank transaction confirmation system according to claim 1,
The server, when receiving via the communication network a request from the communication terminal of the consignor, further comprising a transfer request content output unit which outputs the total vibration data to the communication terminal of the consignor Feature bank transaction confirmation system.
請求項1記載の銀行取引確認システムにおいて、
前記契約情報DBは、送金代行契約の情報に加えて、委託者が送金を承認/否認する場合の送金承認情報を受託者及び委託者の情報、若しくは契約情報に関連付けて格納するものであることを特徴とする銀行取引確認システム。
In the bank transaction confirmation system according to claim 1,
The contract information DB stores remittance approval information when the consignor approves / denies remittance in addition to the information of the remittance agent contract in association with the information of the trustee and the consignor or contract information. A bank transaction confirmation system.
請求項4記載の銀行取引確認システムにおいて、
前記契約情報DBは、受託者毎に異なる送金承認情報を委託者の識別情報若しくは契約情報に関連付けて格納するものであることを特徴とする銀行取引確認システム。
In the bank transaction confirmation system according to claim 4,
The bank information confirmation system, wherein the contract information DB stores remittance approval information that differs for each trustee in association with the identification information or contract information of the trustee.
請求項1記載の銀行取引確認システムにおいて、
前記サーバの送金依頼承諾処理部は、前記委託者の通信端末から送金否認情報を通信ネットワークを介して受信した場合に、この総振データの取消しを指示する情報を前記金融機関ホストに対して出力する総振取消指示出力部を有し、
前記金融機関ホストは、総振データ取消指示を受信した場合に、該当する総振データの取消しを実行する総振取消実行部をさらに備えた
ことを特徴とする銀行取引確認システム。
In the bank transaction confirmation system according to claim 1,
When the remittance request acceptance processing unit of the server receives remittance refusal information from the communication terminal of the consignor via a communication network, the remittance request acceptance processing unit sends information to instruct the financial institution host to cancel the total transfer data It has a total cancellation instruction output unit that outputs,
The bank transaction confirmation system according to claim 1, wherein the financial institution host further includes a total reversal executing unit that cancels the corresponding total reversal data when receiving a total reversal data cancel instruction.
金融機関に設けられたサーバと送金処理を行う金融機関ホストとを有する銀行取引確認システムによって、所定の送金先への送金手続きの代行を委託する委託者・受託者及び当該送金先の間の銀行取引の確認を行う方法であって、
前記サーバは、前記受託者及び委託者の通信端末と通信ネットワークを介して夫々接続され、
この方法は、
前記サーバの送金依頼受付部が、前記受託者が作成し、この受託者及び委託者を特定するための情報と送金先の口座の情報と送金先に送金する資金を引き落とす受託者若しくは委託者の口座の情報とを含む送金依頼情報(総合振込データ:以下「総振データ」と略す)を当該受託者の通信端末から通信ネットワークを介して受信して受託者若しくは委託者の銀行口座内の資金を所定の送金先口座へ送金するための送金依頼を受け付けると共に、この総振データを前記金融機関ホストに送信する送金依頼受付工程と、
前記サーバの契約情報確認部が、前記送金依頼を受け付けた場合に、委託者と受託者との間で締結された送金代行契約の情報を格納する契約情報データベース(DB)にアクセスして、前記総振データに含まれる委託者及び受託者を特定する情報に基いて当該受託者と委託者との間の送金代行契約の情報を確認する契約情報確認工程と、
前記サーバの送金依頼承諾処理部が、送金代行契約が確認できた場合に、この委託者の通信端末に対して総振データを含む送金承認要求情報を作成して通信ネットワークを介して送信し、委託者の通信端末からの送金承認情報を通信ネットワークを介して受信すると共に、前記金融機関ホストに対して送金処理の指示を送信する送金依頼承諾処理工程と、
前記金融機関ホストの送金処理部が、前記サーバの送金依頼承諾処理部から送金処理の指示を受信した場合に、前記送金依頼受付部から受信した総振データに含まれる受託者若しくは委託者の口座から送金先の口座に対してこの送金依頼に係る送金処理を実行する送金処理工程と
を有することを特徴とする銀行取引確認方法。
A bank between a consignor / trustee who entrusts a transfer procedure to a specified remittance destination by a bank transaction confirmation system that has a server provided at the financial institution and a financial institution host that performs remittance processing, and the remittance destination bank A method for confirming a transaction,
The server is connected to the trustee and the communication terminal of the consignor via a communication network, respectively.
This method
The remittance request acceptance unit of the server is created by the trustee and includes information for identifying the trustee and the consignor, information on the account of the remittance destination, and the trustee or consignor who withdraws funds to be transferred to the remittance destination. Remittance request information including the account information (general transfer data: hereinafter referred to as “total transfer data”) is received from the trustee 's communication terminal via the communication network and stored in the trustee's or trustee's bank account. A remittance request accepting step of accepting a remittance request for remittance of funds to a predetermined remittance destination account, and transmitting this total distribution data to the financial institution host;
The contract information confirming unit of the server, when receiving the transfer request, and access to contract information database (DB) that stores the information of the fastening has been remittance agency contract between the consignor and the trustee, said A contract information confirmation process for confirming information of a transfer agent contract between the trustee and the trustee based on information identifying the trustee and the trustee included in the total data ,
When the remittance request acceptance processing unit of the server confirms the remittance agent contract, it creates remittance approval request information including the total data to the consignor 's communication terminal and transmits it via the communication network , Remittance request approval processing step of receiving remittance approval information from the communication terminal of the consignor via the communication network, and transmitting a remittance processing instruction to the financial institution host,
When the remittance processing unit of the financial institution host receives a remittance processing instruction from the remittance request acceptance processing unit of the server , the account of the trustee or the consignor included in the total transfer data received from the remittance request reception unit And a remittance processing step of executing remittance processing related to the remittance request for the remittance destination account .
JP2001379055A 2001-12-12 2001-12-12 Bank transaction confirmation system and method Expired - Lifetime JP4064664B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2001379055A JP4064664B2 (en) 2001-12-12 2001-12-12 Bank transaction confirmation system and method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2001379055A JP4064664B2 (en) 2001-12-12 2001-12-12 Bank transaction confirmation system and method

Publications (2)

Publication Number Publication Date
JP2003178198A JP2003178198A (en) 2003-06-27
JP4064664B2 true JP4064664B2 (en) 2008-03-19

Family

ID=19186582

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001379055A Expired - Lifetime JP4064664B2 (en) 2001-12-12 2001-12-12 Bank transaction confirmation system and method

Country Status (1)

Country Link
JP (1) JP4064664B2 (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5089678B2 (en) * 2009-12-24 2012-12-05 株式会社三菱東京Ufj銀行 Fund transfer processing data transmission apparatus, fund transfer processing data transmission program, and fund transfer processing data transmission method
JP5700716B2 (en) * 2013-06-06 2015-04-15 株式会社日本総合研究所 Remittance control system and program
JP6055050B1 (en) * 2015-08-28 2016-12-27 株式会社三井住友銀行 Bank system, method and program executed by bank system

Also Published As

Publication number Publication date
JP2003178198A (en) 2003-06-27

Similar Documents

Publication Publication Date Title
US7120606B1 (en) System and method for secure electronic fund transfers
US7343349B2 (en) System and method for secure data and funds transfer
CA2244627C (en) Method and apparatus for managing electronic money and storage medium for storing an electronic money management program
US20110041158A1 (en) System and method for message handling
US20020049670A1 (en) Electronic payment method and system
US20030036999A1 (en) Electronic presentation of invoices using a trusted document repository
US8725605B1 (en) Method and system for managing service accounts
CN116830137A (en) System and method for performing real-time electronic transactions using API calls
JP4152607B2 (en) Remittance system, remittance relay device, and account confirmation method
JP4064664B2 (en) Bank transaction confirmation system and method
KR20090036165A (en) System and method for transfering mail banking linked online account and recording medium
KR100709726B1 (en) Electronic account settlement apparatus, electronic settlement method, and recording medium for storing a computer-program
KR20040033696A (en) Escrow service system and method of the same and media that can record computer program sources of the same
KR20010056244A (en) System and method for electronic bill presentment and payment using gateway server
JP7109717B2 (en) Remittance support server, remittance support system, remittance support method, and program for executing remittance support method
JP2011134141A (en) Apparatus, program and method for processing payment
KR100999990B1 (en) System and method for safely transferring money on deposit
KR20000037389A (en) Account transaction brokerage system and the method thereof using mobile phone or E-mail
KR100706199B1 (en) A system for network-based rent management service and service method thereby
JP2005044289A (en) Payment system, transfer operation terminal, financial institution server, withdrawal operation terminal, computer program and payment method
CN115345722B (en) Fund management system, method, electronic device and storage medium
JP6228651B1 (en) Transfer system and method on the premise of receiving side approval
KR20090029248A (en) System for transferring fund between online accounts by using enterprise intranet
KR101735156B1 (en) Method for Relaying the Integrated Issue of Confirm Letter of Bank Deposit
KR100485243B1 (en) payment method by on-line account commerce using security system

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20041129

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20060413

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20061124

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20061128

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070124

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070309

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20070309

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20070710

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070906

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20070919

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20071218

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20071227

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 4064664

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110111

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120111

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120111

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130111

Year of fee payment: 5

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130111

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140111

Year of fee payment: 6

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term