はじめに
この記事は、FAPIについて正しくまとめようとした記事ではなく（それが必要な方はこちらを参照ください）、認証・認可の初心者がどのようにFAPIを捉えるか、という目線で書かれています。
ご指摘など大歓迎ですので、ぜひコメントください。
FAPIとは
金融機関サービスのためのAPIの標準だと思っています。
金融機関のサービスを一部利用できるアプリでは、（現在もそうかは知りませんが）銀行のWebサイトを、ユーザーが入力したIDとパスワードでスクレイピングしてAPIエンドポイントのように利用しているケースがありました。
これをOAuthのモデルで解決するのがFAPIであり、OpenID FoundationのWorking Groupで議論が進められています。
金融機関で求められるセキュリティを担保するため、OAuthのモデルに則りつつもより強い勧告をしたり、仕様の追加をしているものと思われます（まだFAPIの仕様を読みきっていない & 基本的なOAuthの仕様と比較していないので推測ですが）
基本的なOAuthだけでは何が問題なのか？
クライアントアプリ ←→ クライアントサーバー ←→ 金融サービス の間で、特に認可グラントのフローにおいてメッセージの送信元・送信先・メッセージ内容が正しいかどうかを確認できないのが問題のようです。
そのほか、クライアントサーバーの内部ではグラントやアクセストークンなどを暗号化しないとか？などの観点もあるようです。
メッセージの送信元
- 金融サービスがクライアントのブラウザ/アプリからのリクエストをクライアントのサーバー経由で受け取る時、それが本当に認可対象のエンドユーザー由来のリクエストなのか？を確かめたい
- クライアントのブラウザ/ アプリがサーバー経由で金融サービスのレスポンスを受け取る時、それが銀行になり済ました悪意あるサービスではないかを確かめたい というニーズがあるようです。
メッセージの送信先
- クライアントのサーバー（例えばお財布アプリのバックエンド）がスマホアプリに対して認可グラントを送るとき、スマホがマルウェアに感染していてURLスキーマが乗っ取られていたら、その認可グラントが悪意あるアプリに取って行かれてしまう、のが問題のようです。
どのように対策するか？
FAPIの仕様では読み取り専用のAPIと読み書き可能なAPIで対策を分けています。
読み取り専用のAPIのためのフローでも基本的なOAuthよりも厳しくなっており、さらに多様な攻撃を想定したセキュリティを仕様に組み込んだのが読み書き可能なAPI、という枠組みで仕様を読み進めるのが良さそうです。
おわりに
ここに書いたことは全てFAPIの資料の解釈です。
もし他にもこんな記事が参考になるよ、とか、こんな勉強会してるよ、などの情報があればぜひコメントください。