あらゆるM-Pesa SMS形式からトランザクションコード、金額、取引相手を認識

フィールドを特定するアプリUIがない。 VenmoやPayPalにはレイアウトの手がかりとなる視覚的な画面があります。しかしM-Pesaのレシートは生のSMSであり、太字の見出しも色もありません。アプリのインターフェース向けに設計されたOCRツールは、視覚的に固定するものがないため失敗します。

1つのメッセージに3つのKsh金額があり、そのうち1つだけが取引金額。 送金金額、取引手数料、新しい残高はすべてKshという接頭辞を共有しています。「Kshの後の数字」を取得する正規表現ルールは、しばしば間違った数字を拾ってしまいます。正規表現でM-Pesa SMSを解析する開発者は、メッセージタイプごとに正しいKshの出現箇所を特定する必要があり、この脆弱性がフォーマット間で問題を引き起こします。

取引相手の形式が取引タイプごとに異なる。 「Sent to JOHN DOE 0722000000」は個人を指します。「Paid to Naivas Supermarket」は事業者を指します。「AC for account 1137238445」は請求書支払いです。文法構造が形式ごとに異なるため、1つの正規表現ルールですべてを処理することはできません。

トランザクションコードは常に最初の単語です。 すべてのM-Pesa SMSは10文字のコードで始まり、その後に"Confirmed"が続きます。AIはこの一貫した開始部分をアンカーとして利用します。メッセージをテキストとして読み取り、位置に基づいてコードを特定し、そこから残りの抽出を構築します。

ラベルが各Ksh金額の意味を決定します。 "Transaction cost, Ksh6.00"は手数料としてタグ付けされます。"New M-PESA balance is Ksh1,205.10"は残高としてタグ付けされます。"sent to"または"received"の後に続く値のみが金額列に入力されます。位置の仮定なしに、意味的に異なる3つの数値が解決されます。

取引相手は意味的な役割によって識別されます。 SMSが"sent to JOHN DOE"、"paid to Naivas Supermarket"、または"received from MICHAEL FEDERSEN"のいずれであっても、AIは取引の相手側のエンティティを取引相手列にマッピングします。特定のキーワードの位置ではなく、関係性を読み取ります。