あらゆる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.」が続き、最後は一貫したフッター「PIN YAKO SIRI YAKO」（スワヒリ語で「あなたのPINはあなただけの秘密」）で締めくくられます。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は取引の相手側のエンティティを取引相手列にマッピングします。特定のキーワードの位置ではなく、関係性を読み取ります。