Yes, this tx has only the signatures in the V_IN part (unlocking script), no public keys directly behind it, or a redeemscript. The V_OUT part (locking script) has a redeemscript for a 2-of-3 multisig. Usually one would expect a redeemscript hash in the pubkeyscript, but here it is the plain hex codes. So it is an old type multisig (not using P2SH). The unlocking script is the two signatures, and locking script provides the required pubkeys.

So what would happen on the stack:

<sig1>

<sig2>

<redeem script data> ("2" pk1 pk2 pk3 "3" CHECK_MULTISIG)

In a first step the unlocking script is executed, and if valid (results in a TRUE value, or no remaining operators remain on the stack), the tx would be marked as valid. It only pushes data (the signatures), so ok. Then the second step would clear the stack, and sigscript and pubkeyscript would be pushed and executed. As one can see, the three elements on the stack can be resolved to TRUE, and as such it is a simple multisig. Decoding the pubkeys in the redeem script shows:

5221037BF122821AE522F67B7BC09387C2907607CDD66E6BD67BCB53F39D5346ADC74821033E81519ECF373EA3A5C7E1C051B71A898FB3438C9550E274D980F147EB4D069D21027AA4A8DAFFF9B6307899BB7762BF92C50ABDE14C3636719FFC4D4FABF3DC6B0F53AE

    52: OP_2
    21: OP_Data21 (= decimal 33)
        037BF122821AE522:F67B7BC09387C290
        7607CDD66E6BD67B:CB53F39D5346ADC7
        48
        bitcoin address:   18pvHhDLrGJpJ7SznnoxxFdwPnKCqjqVCj
    21: OP_Data21 (= decimal 33)
        033E81519ECF373E:A3A5C7E1C051B71A
        898FB3438C9550E2:74D980F147EB4D06
        9D
        bitcoin address:   1JXc8zsSeAPwqfAzLbBnZxNTfetZexH2bW
    21: OP_Data21 (= decimal 33)
        027AA4A8DAFFF9B6:307899BB7762BF92
        C50ABDE14C363671:9FFC4D4FABF3DC6B
        0F
        bitcoin address:   1BDp6sR3bHH8ACzbwZccY4y9GohG3KX828
    53: OP_Data53 (= decimal 83)
    AE: OP_CHECKMULTISIG

So just an "old type" multisig transaction.