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

フィールドを固定するアプリUIがない。 VenmoやPayPalには視覚的な画面があります。M-Pesaの領収書は生のSMSです。太字の見出しも色もありません。アプリのインターフェース向けに設計されたOCRツールは、視覚的な構造がないと機能しません。

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

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

トランザクションコードは常に最初の単語です。 すべてのM-Pesa SMSは10桁のコードで始まり、「Confirmed.」が続き、最後は「PIN YAKO SIRI YAKO」という定型文で締めくくられます。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は取引の相手側の主体を取引相手列にマッピングします。特定のキーワードの位置ではなく、関係性を読み取ります。