PayNow決済スクリーンショット
金額と受取人の抽出方法
顧客がWhatsAppでスクリーンショットを送ってきます。銀行アプリの決済確認画面が写っています。DBSデジバンクの緑のバナー、OCBCデジタルの白いカード、UOB TMRWの暗いスライド決済画面などです。SGDでの金額が見えます。受取人を識別する情報も見えます。「末尾1234」で終わる携帯番号か、UENと呼ばれる英数字の文字列です。画面下部には自由記述のメモがあるかもしれません。「請求書 #1042」や「3月分チャージ」、あるいは何もない場合もあります。スクリーンショットが取引の唯一の記録です。しかしPayNowはスタンドアロンアプリではなく、各銀行のインターフェースに組み込まれています。そのため、これら3つのフィールドの見え方は、どの銀行の顧客が画像を送ってきたかによってまったく異なります。

重要なポイント
- PayNowはシンガポールの単一の国内決済システムですが、DBSデジバンクの確認画面とUOB TMRWの確認画面はまったく異なります。PayNowには独自のアプリがないためです。
- 9つの銀行アプリはそれぞれ、金額、受取人プロキシ、メモ欄を各社のデザインチームが決めた場所に配置しています。テンプレートベースの抽出では、銀行ごとに個別の設定が必要です。
- セマンティック抽出は確認画面をデータとして読み取り、「SGD 150.00」をその意味に基づいて取引金額として識別します。そのため、1つの列定義で銀行ごとのテンプレートなしに9つすべての銀行に対応できます。
PayNowのスクリーンショットが他の決済アプリのスクリーンショットと異なる理由

PayNowは、シンガポール銀行協会(ABS)が2017年7月に開始し、シンガポール金融管理局(MAS)が監督する、銀行連携の即時送金システムです。FAST(高速安全送金)ネットワークを通じて取引を処理するため、資金は年中無休・24時間体制で数秒のうちに口座間を移動します。OCBCのグループCEOであるタン・テックロン氏が2026年6月のABS年次晩餐会で述べたところによると、2025年12月時点でシンガポールには1,100万件以上のPayNowプロキシ登録がありました。
それぞれ独自のアプリと一貫した確認画面を持つVenmo、WeChat Pay、GCashとは異なり、PayNowには専用アプリがありません。スマートフォンで「PayNow」を開くのではなく、DBSデジバンク、OCBCデジタル、UOB TMRWなどの銀行アプリを開き、その中でPayNowオプションを選択します。取引が完了すると、確認画面はPayNowというブランドではなく、その銀行のものになります。その結果、視覚的な断片化が生じます。3つの主要な銀行アプリが同じ支払いデータを3つの異なるレイアウトで表示するのです。チャットアプリに埋め込まれた支払いスクリーンショットに適用されるのと同じ原則 — インターフェースが領収書でなくてもデータは存在する — がここにも当てはまります。ただし、断片化の原因はメッセージング層ではなく銀行層にある点が異なります。
これは重要です。なぜなら、PayNowのスクリーンショットからほとんどの人が必要とする項目 — 取引金額、受取人識別子、支払いメモ — はすべて各銀行の確認画面に存在しますが、各銀行によって配置が異なるからです。DBSデジバンクの確認画面では金額が上部に大きな緑色のテキストで表示され、その下に受取人が表示されます。OCBCデジタルのレイアウトでは金額が中央の白いカードに表示され、その下に受取人のプロキシが表示されます。UOB TMRWでは確認全体がダークなスライド決済バーの中に収められています。同じPayNow取引でも、3つの異なる銀行から取得すると、視覚的に異なる3つのスクリーンショットが生成されます。
金額 — 常にSGDだが、表示位置は必ずしも同じではない
PayNowの取引はすべてシンガポールドルで行われます。為替レートも、複数通貨の表示も、表示金額から差し引かれる手数料もありません。確認画面に表示される金額は、送金者から受取人へ実際に移動した金額と正確に一致します。金額は各銀行のPayNow確認画面で最も目立つ要素ですが、その正確な配置は銀行によって異なり、複数のソースからスクリーンショットを処理する際には重要なポイントとなります。
DBSデジバンクでは、送金成功画面の上部3分の1を占める緑色のバナーに金額が大きな太字で表示されます。「SGD 150.00」のように、ドル金額が中央に配置され、「SGD」のプレフィックスがその上に小さめの文字で表示されます。金額の下には、銀行のPayNowルックアップに登録されている受取人名が小さな白文字で表示されます。OCBCデジタルでは、確認画面はカードベースのアプローチを採用しており、金額は画面中央の白い長方形の中に表示され、その上に「金額」というラベルが付き、受取人のプロキシ情報はカードのさらに下に表示されます。UOB TMRWでは、確認情報は下部のダークグレーの確認バーに埋め込まれ、金額は緑のチェックマークの横に目立つように表示され、受取人情報はその上にメッセージ形式のレイアウトで表示されます。
異なる銀行を利用する顧客、クライアント、同僚からPayNowのスクリーンショットを受け取る担当者にとって、金額は扱いやすいフィールドです。常に存在し、常に表示され、その意味が曖昧になることはありません。課題となるのは、テンプレートベースの抽出アプローチ(特定のピクセル座標で金額を探す方法)では、DBS、OCBC、UOB用に3つの別々のテンプレートが必要になり、さらにHSBC、Maybank、Standard Chartered、Citibankなどの他の参加銀行向けの追加バリエーションも必要になることです。一方、セマンティック抽出アプローチでは、画面上の金額の位置は関係ありません。確認画面全体を読み取り、支払い確認の文脈で「SGD 150.00」が何を意味するかを理解することで、どの値が取引合計額かを特定します。
受取人 — 表示名ではなくUENまたは携帯番号
このフィールドは、このシリーズの決済アプリの中でPayNowのスクリーンショットを特徴づける要素です。Venmoでは受取人は@ユーザー名です。WeChat Payでは加盟店の登録名です。PayNowでは、受取人の識別子はマスクされた携帯番号(「+65 XXXX 1234」のように中央の数字が隠れて表示される)またはUEN(事業登録番号)のいずれかです。UENは、シンガポールの会計企業規制庁(ACRA)が発行する標準的な事業登録識別子です。

個人間送金の場合、送金者が受取人の携帯番号またはNRIC/FINを入力すると、PayNowの照会システムが返す名前が表示されます。この名前(プロキシに関連付けられた「PayNow名」)が確認画面に表示されます。ただし重要なのは、これは受取人が選んだユーザー名ではないということです。これは受取人の銀行に登録されている名前であり、受取人の登録内容によって、正式名称、事業名、ニックネームのいずれかになる可能性があります。送金者から受取人に送られるスクリーンショットには、この名前がマスクされたプロキシとともに表示されます。個人間送金ではUENは一切関与しません。
事業者向け支払いの場合、受取人の識別子はUENです。UENは9〜10桁の英数字(例:201422384R)で、シンガポールの事業税IDと会社登録番号を兼ねたものです。顧客がPayNowで事業者に支払う場合、事業者のPayNow QRコードをスキャンするか、UENを手動で入力します。確認スクリーンショットでは、UENが受取人識別子として表示され、銀行によって「PayTo」や「受取人UEN」などのラベルが付くことがよくあります。一部の銀行はUENを完全に表示し、他の銀行は中央の文字をマスクします。登録事業名(ACRAに登録されている名前)も確認画面に表示され、送金者が送金を確定する前の検証ステップとして機能します。これは、PayNowが運用されるMAS電子決済フレームワークで説明されているのと同じ照会システムです。送金者は登録事業名を確認し、意図した受取人と一致するか検証できます。
抽出における実際的な影響:人間が読める受取人名を探して「支払先」列にコピーするのではありません。探すべきは2種類の識別子のいずれかであり、スクリーンショットだけではどちらを見ているか判別できない場合があります。「1234」で終わる携帯番号と「201422384R」のようなUENは、PayNowのシステムでは同じ目的(受取人の一意な識別)を果たしますが、記録上ではまったく異なる意味を持ちます。携帯番号は個人として誰がお金を受け取ったかを示します。UENは登録事業者であることを示します。顧客口座や仕入先記録に対して支払いを照合する際、これらを取り違えると、取引が誤った元帳に記録されることになります。
メモ・備考欄 — 記録とのつながりがここにある
PayNowでは、送金者は取引ごとに自由記述のメモを添付できます — 銀行のインターフェースにもよりますが、最大約40文字です。DBSデジバンクでは、送金画面で確認前に「受取人へのメモ」としてメモを入力します。OCBCデジタルでは「参照」または「備考」と表示されます。UOB TMRWでは、送金フロー中に「説明」フィールドとして表示されます。取引完了後、このメモは確認画面に表示され、受取人の銀行明細書にも取引とともに表示されます。
PayNow Corporate — UENを銀行口座に紐付ける法人向けバージョン — を利用する事業者にとって、このメモ欄は支払いと請求書・注文・顧客口座とのつながりが存在する場所です。動的PayNow QRコードは、一意の請求書番号や注文IDをメモ欄に自動的に埋め込むことができ、顧客が何も入力しなくても、すべての入金に独自の参照情報が付与されます。静的QRコードや手動のUEN送金の場合、顧客は自由に入力するため、メモ欄には請求書番号、顧客名、「3月分リテイナー」のような支払い目的、または何も記載されない場合があります。
スクリーンショットに意味のあるメモがあるかどうかは、その支払いがどのように開始されたかについて重要な情報を示します。「INV-2026-071」を含むメモは、顧客が請求書番号を手動で入力したことを意味し、他の照会なしでこの支払いを請求書システムに照合できます。メモ欄が空白の場合、スクリーンショットには支払いの文脈が表示されておらず、特定の顧客や注文に結び付けるには、金額と受取人を銀行明細書と照合する必要があります。抽出結果の空のセルは有益な情報です — スクリーンショットだけでは完全な照合に不十分であり、その行が手動での確認を必要とすることを示しています。
検証が重要な理由 — 偽造PayNowスクリーンショット問題
シンガポールには、偽造されたPayNowスクリーンショットに関する現実的かつ記録された問題があります。2024年11月、CNAは、編集されたPayNowスクリーンショットを使用して、2022年5月から2023年8月までの35回にわたり、カトンのレストランから約S$3,892相当の食事を騙し取った33歳の女性の事件を報じました — 彼女は自分自身に送金し、スクリーンショットを編集して自分の情報をレストランの情報に置き換え、偽造画像をWhatsAppで転送しました。2024年12月、シンガポール警察は、被害者がクレジットカードや個人情報を取得するように設計された偽のPayNowウェブサイトに誘導するテキストメッセージを受信したPayNowフィッシングキャンペーンに関する勧告を発表しました。r/askSingaporeでは、ユーザーが定期的にPayNowスクリーンショットを投稿して「これは本物に見えますか?」と質問しており、回答の多くは、フォントの間隔、配置、または金額の書式によって偽造が判別できるが、それは見分け方を知っている人に限られるというものです。

これにより、PayNowを受け付けるすべてのシンガポール事業者が抱えるジレンマが生じます。スクリーンショットは顧客が送ってくるものですが、同時に詐欺師が偽造するものでもあります。解決策はスクリーンショットの受け付けをやめることではありません。Carousellの出品者、レストラン経営者、サービス提供者が、取引の流れを損なわずにすべての顧客に「まず銀行アプリを確認します」と言うことはできないからです。解決策は、スクリーンショットを証拠ではなく検証の出発点として扱うことです。スクリーンショットから金額、受取人識別子、メモを抽出します。次に、それらの項目を銀行明細書またはアプリ内の取引履歴と照合します。実際のPayNow取引は即座に口座に反映されます。FASTネットワークは数秒で決済されるため、検証は瞬時に行えます。偽造されたスクリーンショットは、銀行アプリで取引を探しても何も見つからなかった瞬間に明らかになります。
ファイルは安全に処理され、保存されません。
PayNowスクリーンショットのバッチに対する抽出の流れ
DBSデジバンク、OCBCデジタル、UOB TMRWなど、さまざまなアプリからのPayNowスクリーンショットのバッチをアップロードし、金額 (SGD)、受取人、受取人タイプ (携帯/UEN)、メモ、取引日の列を定義すると、抽出エンジンは各フィールドの意味を理解して、各スクリーンショット上の対応する値を特定します。金額は確認画面の中で最も大きい通貨表記の数字です。受取人はプロキシラベルと対になっている識別子です。メモ欄は備考セクションに表示される自由記述の文字列です。各スクリーンショットから1行が生成され、すべての行が1つのスプレッドシートに統合されます。
受取人タイプにおける携帯番号とUENの区別は、明示的に追加する価値のある列です。受取人タイプ (携帯/UEN)を列定義に含めると、AIは受取人の識別子が電話番号か事業登録番号かを形式に基づいて識別します。UENは明確なパターン(9〜10文字の英数字で、末尾が英字)に従い、携帯番号(+65で始まる)とは異なります。この分類により、個人への支払いと事業者への支払いをダウンストリームの照合で分けてフィルタリングできるため、消費者向けとB2Bの両方の取引を同じシステムで処理する場合に特に役立ちます。
このデータの出力先としてよく使われるのは、シンガポールの中小企業の間で最も広く利用されている2つのクラウド会計プラットフォーム、Xero SGまたはQuickBooks Online SGです。XeroはIRAS F5/GST申告とInvoiceNow電子請求書に対応し、QuickBooksは小規模チームやフリーランサーに人気があります。ABSS(旧MYOB、年間S$349)とAutoCount(月額S$35)は、会計に加えてより強力なオンプレミスの在庫管理を必要とする企業向けです。これらのプラットフォームはいずれも、WhatsAppで転送されたDBSデジバンクのスクリーンショットをネイティブに取り込むことはできません。「顧客がPayNowスクリーンショットを送ってきた」から「データが帳簿に入った」までのステップは、ほとんどのシンガポール企業では依然として手作業です。抽出は、各スクリーンショットを構造化された行に変換して、企業が使用している会計システムにインポートまたはコピーできるようにすることで、そのギャップを埋めます。
PayNowと並行して他のアプリからの支払いも処理する場合 — フィリピンの仕入先からのGCash、韓国のクライアントからのKakaoPay、海外の顧客からのPayPal支払い — 同じ列定義がアプリごとの設定なしで全てに適用されます。金額、受取人、日付、参照は普遍的なものです。複数アプリの支払いスクリーンショットのワークフローは、これらすべてのアプリのスクリーンショットを1つのスプレッドシートに統合します。これらすべてを支える原則は同じです。出力列を定義すれば、AIは画像を生成した銀行や支払いアプリに関係なく、各スクリーンショット上の該当する値を用語の意味を理解して見つけ出します。
よくある質問
WhatsAppの圧縮を経由して送信されたPayNowスクリーンショットからデータを抽出できますか?
はい、圧縮された画像全般に当てはまる精度上の注意点は同じですが、可能です。WhatsAppは画像を大幅に圧縮するため、文字の輪郭がぼやけることがあります。しかし、視覚AIモデルは文字を1文字ずつではなく文脈全体で読み取るため、従来のOCRよりもJPEG圧縮による画質劣化に強く対応できます。クリーンな抽出のためには、WhatsAppで転送された画像ではなく、送信者に元のスクリーンショットを共有してもらうことをお勧めします。すでに圧縮されたスクリーンショットの場合でも、金額と受取人識別子(どちらも大きく明瞭なフォント)は確実に読み取れます。小さめの文字で表示されるメモ欄は、目視での確認が必要な場合があります。
PayNowの確認画面がHSBC、Maybank、スタンダードチャータードなど、あまり一般的でない銀行の場合はどうなりますか?
PayNowはシンガポールで事業を展開する主要な銀行すべてでサポートされています。DBS/POSB、OCBC、UOB、HSBC、Maybank、スタンダードチャータード、シティバンク、中国銀行、ICBCなどです。各銀行の確認画面のレイアウトは異なりますが、フィールドは一貫しています。SGD建ての金額、受取人のプロキシ(携帯番号、NRIC/FIN、またはUEN)、任意のメモ欄です。セマンティック抽出アプローチは特定の銀行のテンプレート照合に依存せず、スクリーンショットを生成した銀行のインターフェースに関係なく、これらのフィールドを意味と画面上の視覚的役割に基づいて識別します。
PayNowスクリーンショットのデータを信頼する前に、その真正性を確認するにはどうすればよいですか?
PayNow取引はFASTネットワークを通じて即時に決済されます。スクリーンショットが支払い完了を示している場合、銀行アプリまたはインターネットバンキングの取引履歴を確認してください。数秒以内に資金が反映されるはずです。スクリーンショットだけに頼らないでください。照合の際は、スクリーンショットから金額と受取人識別子を抽出し、アプリ内の取引記録と突き合わせてください。この2段階のワークフロー(抽出してから検証)が企業が採用すべき方法であり、抽出したデータを構造化された形式(手書きのメモや写真アルバムではなく)で保持することが、大規模な検証を実用的にする理由でもあります。
異なる銀行のPayNowスクリーンショットをまとめてバッチ処理できますか?
はい。DBSデジバンク、OCBCデジタル、UOB TMRWのスクリーンショットは、同じバッチにアップロードできます。列を一度定義すれば、抽出エンジンが同じ列定義をバッチ内のすべてのスクリーンショットに適用し、統合されたテーブルを出力します。各行は1つの取引を表し、定義に「銀行」列を含めると、確認画面の視覚的なスタイルから取引元の銀行を識別できます。これは、PayNowの特定のフィールド構造に合わせて調整された、スクリーンショットからスプレッドシートへのワークフローと同じもので、一般的に支払いプラットフォーム全体に適用されます。